[lkml]   [2001]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: A signal fairy tale
At 10:59 AM 6/28/2001 -0400, Dan Maas wrote:
>life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation
>into queued, information-carrying siginfo signals just shows how badly we
>need a more robust event model... (what would truly kick butt is a unified
>interface that could deliver everything from fd events to AIO completions to
>semaphore/msgqueue events, etc, with explicit binding between event queues
>and threads).

I guess this is my thinking: it's really not that much of a stretch to make
signals behave like GetMessage(). Indeed, sigopen() brings them
sufficiently close. By doing this, you DO provide this unified interface
for all the different types of events you described which works much like
GetMessage(). So, but adding a couple of syscalls you avoid having to
implement a whole new set of API's for doing AIO, semaphores, msgqueues, etc.


P.S.: What do you mean by explicit binding between event queues and
threads? I'm not sure I see what this gains you.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:17    [W:0.051 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site