Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Wed, 8 Mar 2000 19:50:58 +0000 (GMT) | Subject | Re: Changes in the sockets: SIGIO handling |
| |
Hi,
On Tue, 7 Mar 2000 21:11:04 +0300 (MSK), kuznet@ms2.inr.ac.ru said:
>> IMO a callback device that you simply read() the siginfo from would be >> much the cleaner API.
> Well, batched signal delivery is apparently required feature, > when signals are queued. There are no questions here.
What's the problem? The expected mode of operation here is that the caller will always have the signal blocked and will use sigtimedwait() to dequeue siginfo structures synchronously in place of calling poll().
> But do not forget that even generation of such signals is not a zero > overhead, which can be saved as rule. F.e. both old and rt signals > are not generated at all when someone _sleeps_ in read()/write().
Are you sure? Even if the signal is blocked?
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |