I once thought clicker would rather have system calls like
Code: Select all
CommPort.recv(&msg); // locks until a message arrives
CommPort.monitor(OtherCommPort);
CommPort.monitor(YetAnotherCommPort);
ReadyPort=CommPort.recv(&msg);
// monitors both CommPort, OtherCommPort and YetAnotherCommPort and tells which one has been read.
Yet, at the point of implementing it, i now doubt of my choice... Okay, "select" is somehow boring because - in user mode - you have to scan the bitmap to know what descriptor you can read on. that's common to see code like
Code: Select all
while (1) {
// memcpy the whole bitmap under the hook
ready_fds=read_fds;
readies=select(max_fd,&ready_fds,...);
for (i=0;i<max_fd;i++) {
if (!readies) break; // we're all done.
if (FD_ISSET(ready_fds,i)) {
do_stuff_with_fd(i);
readies--;
}
}
}
which is (imho) one of the ugliest piece of Unix code i can think of ... Yet it has many benefits over my own proposal, for instance it nicely supports priorities amongst the files. e.g. if you decide that file descriptor X should be checked before any of the other, you can just do it in pure user mode. the kernel do not need to be aware of the policy you apply.
So would it make sense to have one API that simply applies FIFO policy and assume everyone will be happy with that, but that where the kernel acts like an "enumerator" of ready handles and one API that returns a bitmap and then let the user code do whatever it wants with that ?
Anyone has experience with a similar API in non-unix systems ?