I'm working on a project that uses libev, and am adding a new feature
that involves dealing with child processes. It seems right to do this
in an event-driven way with ev_child, except for one caveat: I want to
reap them with wait4() rather than waitpid(). The difference between
these is that wait4() provides a struct rusage, giving some statistics
about the child's CPU/memory/etc usage.

So I plan on modifying libev to use wait4(). This might be useful to
other people, so I'm wondering whether it's worth polishing to the
point where it can be merged upstream, and if there are any
significant caveats to be aware of while doing so. In particular, is
it important to preserve the ABI? (Particularly the size of the
ev_child struct. The most obvious implementation adds a large field to
it.) I assume that, since rusage isn't a feature many people need, it
isn't worth breaking ABI compatibility for that alone, but if a
breaking release is already planned it might make sense.

Also, since syscalls are never as well standardized as we wish they
were, is there infrastructure around for making sure my changes don't
break the build on any obscure-but-supported platforms that I can't
test myself?

(To be clear, if this looks like too large a project, I'll make a fork
for my own project's use and leave merging to someone else if they
want to do it. I'm using libev via a C# wrapper, libev-sharp; I don't
mind getting my hands dirty with C, but I'm unlikely to touch perl or
any other wrappers I'm not using.)

Thanks,
Jim Babcock

_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev

Reply via email to