On 3/5/13 8:03 AM, Dirk Engling wrote:
Dear fellow FreeBSD hackers,
while writing a daemon that uses a kqueue to keep track of forked
processes and pipes to userland client code etc, I noticed a lack of
features to implement a proper shutdown without holding data redundantly.
When my daemon quits, I can not ask the kqueue for my installed
filters and get back the udata I passed to the kqueue.
This is unfortunate, because I like the idea of having only one owner
per memory allocation. The most obvious use would be a per-fd-state
held in a memory block. When passing it to kevent() via the udata
entry, I would make this filter the owner of my allocation.
However, when gracefully shutting down, my daemon has no way of
retrieving all the values passed to the filters. For most cases that
may be okay:
memory allocations will just be thrown away on exit(), anyway.
But once I need to clean up external state, like sending signals to
processes I installed an EVFILT_PROC for etc, I need to keep a
redundant list of pids and the associated udata. This violates the
rule of strict ownership and introduces room for inconsistencies.
Is there a specific reason I have overlooked that would forbid popping
untriggered filters from my kqueue? Or is there even a way to do so
that I have missed?
I'm not sure if kqueue support this, however adding such a facility
might be OK.
Another way to handle this is just to make your udata pointers all point
to items in a doubly linked list with the head structure aware of which
kqueue.
Then at the end you can just traverse the list of items you have not yet
popped off.
The only pain here is that it requires managing a doubly linked list and
additional pointer dereferences.
-Alfred
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"