About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Fri, 29 Sep 2006

I know what should be done for kevent so it would be included into mainline, but will not do it.


It is just to add struct sigmask into main kevent function sys_kevent_get_events(). It was done for epoll(), poll() and select() with introducting additional syscall, but let's see what is the reason for such behaviour? Why is it needed at all?

Existing system becomes more and more complex and frequently (if not always) they require some kind of asynchronous notifications, which is done through signals in modern OSes. But frequently delivered signal can not be processed (for example when signal queue overflows), and even if appropriate handler can be called, it is not a good idea to perform complex tasks in signal handler, so it should somehow notify main process about needs to perform additional operations. Frequently sys_poll and friends are called in the core of the event handling state machine, so it is very logical to put there signal processing too, but with usual asynchronous delivery of them it is required to put some locks into handler and also some locks inside the sys_poll() check loop, and even if it is done, with existing design of event delivering mechanisms it is impossible to 100% correctly determine what happend first - signal was delivered or event became ready.
To solve this problem POSIX designed set of special syscalls (sys_ppoll() as addon to sys_poll() for example), which have struct sigmask as parameter, which, if not NULL, means set of signals we are interested in, and if some of those signals happens while we were in usual sys_poll(), they are returned through that parameter. This allows to deliver signals without races, since when sys_ppoll() returns it is either due to one of specified in struct sigmask signals, or due to usual case of error, timeout of ready events.

Let's see why kevent does not need it at all.
Because kevent can drive any kind of events, not only those which are supported by sys_poll(), which means that correct solution instead of POSIX workaround is to just implement signal events as kevent users (like AIO completion) and add them in a usual way into kevent queue. Event readiness is atomic in kevent, which means that whatever happens first: signal or other event, it will be put into the ready queue first. In that case userspace should just check type of the returned event and if it is a signal just perform appropriate operations. People who want struct sigmask there, actually just do not know what kevent is (looking into comments for e-mails I doubt code/mails were even read), and how it is possible to work with it.

That is why I will not add struct sigmask into syscall parameters, and that is why kevent will stuck somewhere where it is now.

But actually I do not care, I did it not specially for the purpose of kernel inclusion (although it would be good), but just because I like it.

I've just thought about situation - it becomes just fun.
There is a very usefull (I do not exaggerate) feature, there are a lot of people who want it included and want to use, there is a demand for it for several years already with regular talks about how it could be implemented, and now when it is done (it is not only done, but with all features requested in empty talks before in mind), it will not be included, just because yet another feature(s) was not added (note, that just added, i.e. it does not require to replace, break or something, just add another kevent user), and people who want that missing feature(s) do not and is not going to implement it, which will force yet another period of time of empty talks and handwaving...
LOL.

But enough, cry is over, I have some interesting work on userspace network stack for netchannels.

/devel/kevent :: Link / Comments ()