Date: Sun, 19 Aug 2007 18:37:55 +0200 From: Tijl Coosemans <tijl@ulyssis.org> To: Daniel Eischen <deischen@freebsd.org> Cc: wine-freebsd@hub.org, src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, "Marc G. Fournier" <scrappy@hub.org>, Robert Watson <rwatson@freebsd.org>, David Xu <davidxu@freebsd.org>, Xin LI <delphij@delphij.net> Subject: Re: cvs commit: src/sys/kern kern_thr.c syscalls.master src/sys/sys Message-ID: <200708191837.56412.tijl@ulyssis.org> In-Reply-To: <Pine.GSO.4.64.0708191027350.16079@sea.ntplx.net> References: <200708160526.l7G5Qg0b008022@repoman.freebsd.org> <20070819092923.X65240@fledge.watson.org> <Pine.GSO.4.64.0708191027350.16079@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 19 August 2007 16:44:09 Daniel Eischen wrote: > Thread id's (as visible to an application) are not required to be > something that is known by the kernel. They certainly are not in > libkse and libc_r, and I don't think they are in libthr either. > This API won't work with libkse (or libc_r if we care) and isn't > guaranteed to work with any future libthreadX. Right, but this is irrelevant. Wine wants all threads to be visible by the kernel (system scope), and uses the kernel thread id to send signals, but also with ptrace for instance. > POSIX has well defined behavior with regard to signaling, and > this certainly bypasses that. If we want to add a more well thought > out set of APIs for thread groups that can (in the future) support > CPU binding and scheduling, then that's OK. But the API as committed > is a hack that solves one particular problem that can be solved in > other (more portable) ways. sigqueue() was mentioned as a possible > solution earlier. There's one immense downside to the sigqueue method though. When you call kill(2) you know the signal has been queued when the call returns and you know the signal will be posted when the thread next crosses the kernel-to-user boundary. With the sigqueue method signal delivery becomes entirely asynchronous and that introduces timing issues. I also don't see this syscall as a hack. It isn't in any portable specification, but it is an understandable extension to kernel threads, which the patch clearly shows because it isn't adding anything new. It's basically only exporting functionality that was already there and will never go away either, because the kernel will always need to send signals to threads.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708191837.56412.tijl>