Messages in this thread | | | Date | Tue, 7 Mar 2000 01:05:56 +0100 | From | Jamie Lokier <> | Subject | Re: Changes in the sockets: SIGIO handling |
| |
kuznet@ms2.inr.ac.ru wrote: > Signal queueing makes this issue much more important, because events > are not merged and signal overhead f.e. when receiving on ethernet > becomes non-trivial.
Calling them signals is a bit bizarre too, as under load the *last* thing you do is pick them up via relatively slow signal delivery.
IMO a callback device that you simply read() the siginfo from would be much the cleaner API. For a start that would give >32 queues, ability to group queues (the device itself may send siginfos to another queue), no problems agreeing with your library which ones you're using, and a "flat file" API which is generally quite nice.. But it's a bit late now.
-- Jamie
- 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/
| |