On Fri, 2011-10-14 at 17:36 -0400, Simo Sorce wrote:
On Fri, 2011-10-14 at 15:27 -0400, Stephen Gallagher wrote:
> On Fri, 2011-10-14 at 13:10 +0200, Pavel Zůna wrote:
> >
https://fedorahosted.org/sssd/wiki/DesignDocs/SigChld
>
>
> That's not exactly what I was looking for (among other things, it
> doesn't account for removal of children that are no longer alive). I
> added an alternate proposal to that page. Please read it and see if it
> makes sense to you.
>
> Also, using the online/offline callbacks as an example wasn't a good
> place to work from. Those are designed the way they are because they can
> be triggered from multiple places, not just the SIGUSR1 and SIGUSR2
> debugging signals.
Isn't a hash table for children a bit overkill ? How many children do
you plan to have ?
Well, my intention was for our design to eventually be proposed for
upstream inclusion into libtevent itself. At that point, we want to make
sure it's fully scalable.
Also, I wanted to account for the possibility that we might eventually
have a backend that requires truly massive numbers of concurrent
children (though I admit the likelihood is small).
I figured a hash table would be most efficient, since the hash function
will tend to keep the internal tree balanced, whereas just using a
b-tree or similar would run into the fact that PIDs *tend* to be
ordered, so the tree would either need to be balanced regularly or it
would just end up heavily right-side weighted (and functionally little
different from a linked list at that point).