Date: Sun, 26 Aug 2001 01:48:55 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: tv@wasabisystems.com Cc: bsd-api-discuss@wasabisystems.com Subject: Re: changes to BSD APIs for THREADS support Message-ID: <200108260548.f7Q5mtE03868@khavrinen.lcs.mit.edu> In-Reply-To: <mit.lcs.mail.freebsd-arch/20010826052748$3c50@traf.lcs.mit.edu> References: <mit.lcs.mail.freebsd-arch/3B885ED0.9DFCA5B5@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <mit.lcs.mail.freebsd-arch/20010826052748$3c50@traf.lcs.mit.edu> you write: >Multithreaded process signal delivery. There's an intricate way that this >is handled in Solaris, as "async signals". More prior art that's probably >worth imitating for code compatibility's sake. I think that POSIX fully (or at least elaborately) specifies this, and note that POSIX does specify a mechanism whereby event notification can instantiate a new thread; see the description of SIGEV_THREAD in the Realtime Signals Extension. One issue, though, is whether programming to meet only the POSIX requirements is sufficient, or whether other, alternative threading models should be supported more directly. I'm agnostic on this issue (especially since I'm not doing the work either way). I'm not clear on whether those other models would require anything substantually different in the way of kernel support, and in any case that may well be a dead end anyway and not worth the time to investigate. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108260548.f7Q5mtE03868>