I have to listen to several filedescriptors and TCP sockets. The TCP sockets are for communication while the filedescriptors are for monitoring and configuring hardware devices. Some of the hardware provides data at a high frequency (>1000/s) while other hardware has a lower update rate (<100/s).
I plan to use kqueue to listen for events. Each time I get an event, I add it to a task list and I wake up a thread from the thread pool. This seems to be pretty vanilla (dixit google).
Also I can trigger an kqueue (see snippet) if need be.
struct kevent trigger;
EV_SET(&trigger, 42, EVFILT_USER, 0, NOTE_TRIGGER, 0, 0);
kevent(queue, &trigger, 1, 0, 0, NULL);
So I could use a single kqueue but I thought of using multiple kqueue's instead. One for the TCP sockets and "slow" hardware and one for each of the "fast" hardware items. Given that I have multiple cores I also thought of dividing the kqueues over the available cores. Or at least dividing the worker threads over the cores by setting the cpu affinity.
I figure this would avoid the fast hardware from monopolising the kqueue. I probably need a way to communicate between kqueue's as well. If one kqueue doesn't (want to) handle an event it gets passed on the next kqueue.
Somewhere I read a throwaway line that kqueue's hierarchies are possible. Unfortunately I haven't found anything more on this.
Before I start hacking away for weeks/months I would appreciate your input. What are your experiences with using multiple kqueue's? Is it a good idea or will I eventually run into problems later on? Is there any example code on using multiple kqueues and hierarchies? Googling "multiple kqueues" leads to ~ "receiving multiple kevents on one kqueue".
Aucun commentaire:
Enregistrer un commentaire