On Thursday 29 June 2006 08:46, Helge Bahmann wrote: > > > what about simply letting thread A/thread B race for event > > > notification? with epoll you can do that (with plain poll obviously > > > you cannot...), and you always get perfect latency (but you don't know > > > which thread will eventually handle the event) > > > > That will not work, because it's thread B that needs the data fetched by > > event handling. Perhaps I should be more precise: > > > > The events are input events from a set of TCP socket. Thread A handles > > input from these sockets and updates state in a subsystem. Thread B > > calls into the subsystem to ask for input. If the required input is not > > available it has to request it from other nodes in the distributed > > system and wait for a reply. In order to minimize the input path for > > thread B, it should do the input handling until the request are replied. > > okay, but what may already be sufficient in that case is: let the threads > race on epoll notification on the same epoll fd, but change wake-up policy > to wake-one and LIFO (I think this policy would generally make sense for > epoll, or at least being able to control it -- the current "wake-all" > policy is not terribly useful IMHO) This would solve the problem. Maybe it should be made possible to define various policies in epoll_create() or with ioctl. > let's assume thread A is already waiting, and thread B requests input; > thread B will then enter epoll_wait after thread A, but still before any > input data is ready (unless the expected response is early, however I > think you can be reasonably sure it will not if it is at all causally > related to the request B just sent) Yes, it is exactly what I need. I also think others would find it usefull. I just stumbled upon an MPI related paper that basically use the same threading model at the cost of extra latency: http://www.ece.purdue.edu/~vpai/Publications/majumder-lacsi04.pdf > this way you are not guaranteed that thread B will take the event, but the > likelyhood should be overwhelming, and probably enough for all practical > purposes -- would you be interested in trying this out? If you are thinking about patching the kernel to support this feature I would definitely like to try it. Right now I'm in the process of finishing my Ph.D. thesis so I'm not sure when I'll have the time. Hans - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
