Brandon Black wrote:
The problem with an initialization flag byte is this then requires
that the memory being passed to the init function be zero-d (or at
least, the flag byte within it be zero-d),
Well, I'd question whether its a problem (certainly not from any performance
perspective) but since it busts the API its not relevant in this case,
clearly,
because the design decision to have the multiple-init bug undetectable is
effectively made. I'm just objecting to Mr Lehman's characteristically
condescending and heavy-handed 'its not possible'.
is basically going to fall into the same class of application
programming bug/mistake as the problem we're trying to avoid in the
first place).
I don't think that's true at all. An API that refuses to work unless the
user has fullfilled
preconditions will tend to be overzealous rejecting calls, and will be
more inconvenient,
but I do think it will tend to have fewer errors. No API will be
completely immune
after all, particularly if you are going to *try* to think of ways that
it *could* be
subverted, rather than accept that the API lends itself to a reinit bug..
Personally I'd be hesitant about overoptimising in a library that is
fundamentally
about calling select in one way or another, and would have thought that
a simple object
pool would be adequate. All that's happened is that we've shifted the
allocation
somewhere else, and it will only actually be a saving if there's a
zero-or-one-to-one
relationship between timers and application entities. All the
timer-centric systems
I've worked with have had timers in the Controller in the overall MVC
and held
them to one side, so I suspect it may not be all that much of a cost
unless you go
for a really malloc-heavy approach with no pooling.
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
