Date: Sat, 18 Aug 2007 20:49:06 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Tijl Coosemans <tijl@ulyssis.org> Cc: wine-freebsd@hub.org, src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@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 thr.h Message-ID: <Pine.GSO.4.64.0708182045260.13363@sea.ntplx.net> In-Reply-To: <200708182118.37998.tijl@ulyssis.org> References: <200708160526.l7G5Qg0b008022@repoman.freebsd.org> <46C4FD02.3090708@freebsd.org> <Pine.GSO.4.64.0708162216530.1396@sea.ntplx.net> <200708182118.37998.tijl@ulyssis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Aug 2007, Tijl Coosemans wrote: > On Friday 17 August 2007 04:33:07 Daniel Eischen wrote: >> Yes, I know it's not needed by libthr :-) I would think you could >> use mq_open(), mq_notify() with sigev_notify = SIGEV_SIGNAL, etc. >> When the receiving process gets the signal, it reads the message >> queue to get the target thread id and the signal to send to it. >> >> It would be nice if we (FreeBSD) did have thread groups, and the >> ability to (soft) bind them to specific CPUs or CPU sets, ala Solaris >> processor_bind(), pset_bind(), etc. Once you have these, then I can >> perhaps see a thrgrp_signal() or something similar since the thread >> group would already be managable outside the context of a process. > > > To be honest, I'm not entirely fond of adding this syscall either, but > from an engineering point of view, it's really the easiest and cheapest > solution right now. That doesn't mean we should have added it. Our APIs that ship for 7.0 need to be maintained for compatibility, and this API is to satisfy just one application (Wine), and only for some of those applications that are run under it. > POSIX message queues aren't needed. Sigqueue() with sigval set to the > thread id would be enough. Then whichever thread receives the signal > can either handle it or dispatch it using thr_kill(). > > Sigqueue() doesn't exist in 6-STABLE though and as I understood will > never be MFC'd, because it involves too many other things (signal > queueing, ksiginfo,...), whereas thr_kill2() is entirely isolated and > trivial to merge. > > Perhaps it should be stressed in documentation that this syscall is > only meant for Wine and to be removed at some point when better > solutions become available. I want to test this sigqueue solution some > more, because the indirection in signal delivery causes trouble when a > thread signals itself. I guess this would have to be special-cased > somehow then. I would rather just use sigqueue in 7.0 if necessary and drop support for some set of applications run under Wine in 6.0. We shouldn't be adding hacks like this to suit just one application... -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0708182045260.13363>