A signal fairy tale
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines
Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO?
I have to agree, in a way... At some point we need to swallow our pride, admit that UNIX has a crappy event model, and implement something like Win32 GetMessage =)...
I've been having trouble finding situations where asynchronous signals are really the most appropriate technique, aside from delivering 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).
Regards,
Dan
Quoted 2 lines
admit that UNIX has a crappy event model, and implement something like Win32 GetMessage =)...
Thats a subset of the real time signal model already in Linux. Just block the signal and wait for it..
Quoted 6 lines · Dan Maas
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.
--Chris
P.S.: What do you mean by explicit binding between event queues and threads? I'm not sure I see what this gains you.
Quoted 8 lines · Christopher Smith
Quoted 6 lines · Dan Maas
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).
Quoted 6 lines
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 likeGetMessage(). 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.
Wouldn't recv/recvfrom/recvmsg suffice? I think they could do the trick. More covenience functions can than be derived in userland library. You still have one type of events per descriptor, but you can combine with poll in userspace library.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>
Quoted 2 lines · Christopher Smith
P.S.: What do you mean by explicit binding between event queues and threads? I'm not sure I see what this gains you.
Cache affinity presumably?
--cw