Date: Sat, 18 Aug 2007 21:18:36 +0200 From: Tijl Coosemans <tijl@ulyssis.org> To: Daniel Eischen <deischen@freebsd.org>, David Xu <davidxu@freebsd.org>, wine-freebsd@hub.org Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Xin LI <delphij@delphij.net>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_thr.c syscalls.master src/sys/sys thr.h Message-ID: <200708182118.37998.tijl@ulyssis.org> In-Reply-To: <Pine.GSO.4.64.0708162216530.1396@sea.ntplx.net> References: <200708160526.l7G5Qg0b008022@repoman.freebsd.org> <46C4FD02.3090708@freebsd.org> <Pine.GSO.4.64.0708162216530.1396@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 17 August 2007 04:33:07 Daniel Eischen wrote: > On Friday 17 August 2007 03:42:26 David Xu wrote: >> Daniel Eischen wrote: >>> On Thu, 16 Aug 2007, Xin LI wrote: >>>> Daniel Eischen wrote: >>>>> On Thu, 16 Aug 2007, David Xu wrote: >>>>>> davidxu 2007-08-16 05:26:42 UTC >>>>>> >>>>>> FreeBSD src repository >>>>>> >>>>>> Modified files: >>>>>> sys/kern kern_thr.c syscalls.master >>>>>> sys/sys thr.h >>>>>> Log: >>>>>> Add thr_kill2 syscall which sends a signal to a thread in >>>>>> another process. >>>>> >>>>> >>>>> I do not think this is a good idea. There is no such thing in >>>>> Solaris, only Linux seems to have this hideous idea of an API. >>>> >>>> >>>> I think this would be helpful for applications like Wine. Is >>>> there any other way to implement the semantics? >>> >>> >>> I realize what it's for, and I don't agree that it belongs in the >>> tree. There are other forms of interprocess communication, pipes, >>> sockets, even msg queues. I'm sure you can find a few ways to send >>> a message to a process to say "send signal X to thread Y" if you >>> really wanted to. It looks like even Linux makes you use a thread >>> group, not a thread. The tgkill() syscall in Linux takes a tgid and a pid as arguments, where pid can be a thread id (obtained with gettid()). >>> I don't see where this was discussed on -arch or -current, but >>> maybe I missed that thread. >> >> >> I've CCe'd Tijl Coosemans to check if there is another way to >> implement the feature in WINE instead of in kernel. in fact, I have >> delayed the the change for a few days, I was thinking you know the >> patch, but the fact is not now. PS, the feature is not required by >> libthr. ;-) > > > 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708182118.37998.tijl>