I am trying to implement a modular filter plug-in system on top of libevent.
The main concept principles are:
1Â) Filters are created cointaining information of connections they should be bound to (protocol, port), events that should trigger them and a callback pointer to link with the event
2Â) Based on those filters, the necessary sockets are created and each socket is linked to a list of filters matching them
3Â) For each filter, an event is created liking the callback to the socket file descriptor
4Â) Each filter is then able to read information from the socket and possibly stack information to write that socket, registering a WRITE event on it
My concern here are concurrency (not really race condition since the app is single-threaded) :
I) If multiple filters ask to be triggered on READ event on the same socket, what will they see? Will they all be able to read the same message which triggered the event and not another one (ie another message received while processing the filter list)?
II) If multiple filters wanna write data to the socket, is it safe to have each filter having its separate buffer and triggering its own WRITE event on it?
Here is a use case summing up both previous inquiries:
Say a filter wrote data to a socket after parsing the content it read on it, and that the peer reacted to that answer, what will subsequent filters, for which the READ event has been triggered by the initial message, read?
a) Initial message?
b) Either initial message or answer (race, undecided)?
c) Nothing since the event has been canceled (not pending anymore), the subsequent filters will only receive a new event for READ on reception of the answer
I am thinking of using a dispatcher which would sequentially (and manually) trigger the event of each of the filters. However that implies not linking the filters event with the socket, thus forcing me to maintain a separate buffer for each of the filter (with memory and processing overhead that implies). Moreover, the problem reappears if another message is received on the socket while the dispatching loop is at work... and the sequential work makes the benefit of the event-based system disappear!
I do not know if the bufferevents would be useful to my case. Anyway, those are not an option, since part of the traffic I am handling is UDP datagrams.
I am new to the library. Please enlighten me if I have missed some key points in its design/handling.