Re: (e)poll takeover

[Helge Bahmann]

> > 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)

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)

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?

Best regards
-- 
Helge Bahmann <hcb@xxxxxxxxxxxxxxx>                     /| \__
The past: Smart users in front of dumb terminals       /_|____\
                                                     _/\ |   __)
Wer im finally-Block sitzt, sollte nicht             \\ \|__/__|
mit exceptions werfen.                                \\/___/ |
                                                        |

-
To unsubscribe from this list: 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