Date: Mon, 22 Oct 2007 18:42:36 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: kthreads->kproc and back to kthread.. next patch Message-ID: <ffijts$tqt$1@ger.gmane.org> In-Reply-To: <471BDA2E.9040801@elischer.org> References: <471BDA2E.9040801@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Here is the link to the next patch. > > this introduces (back) the kthread_create (etc) calls but now they > make threads.. > it may also be worth adding some help for people to make a new kproc, > and populate it with a number of kthreads. For example, why would we do that? :) A practical example: GEOM modules often spawn separate execution contexts to handle non-trivial IO requests. These threads are usually created at most once per GEOM device and live until that device goes away. GEOM framework itself has several execution contexts (g_up, g_down, g_event) which call "methods" from GEOM classes. Should we spawn one "dummy" kproc per GEOM class and then kthreads in it for devices? If "raw" kthreads can be spawned, to which kproc will they belong (if any)? Is the difference between kthread and kproc here purely aesthetic? In other words: when should one create a kproc and when a kthread?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ffijts$tqt$1>