On Mon, Aug 19, 2013 at 1:07 AM, Roland Mainz <[email protected]> wrote: > Hi! > > ---- > > Attached (as "astksh20130814_sigqueuerepeat001.diff.txt") is a patch > which fixes a couple of problems with kill(1)'s |sigqueue()| support. > > ** Changes: > - kill(1) now has a --repeat option to repeat |sigqueue()| if it > returns with |EAGAIN|. It turns out this can happen *very* often if > the |SIGQUEUE_MAX| limit is reached. Since this happens very very > *OFTEN* (and the detection and re-try on shell level a bit cumbersome) > this option is "on" by default for -q/-Q but can be turned off via > --norepeat. If |sigqueue()| is repeated kill(1) calles |sched_yield()| > (see "Notes" below) to prevent the receiving process from being > "starved" away from the CPU. Note that this can never result in an > endless loop as signals are queued in-order by the sending process as > long as there is space in the queue. Priority inversion and other > issues are avoided by using |sched_yield()|.
I'm sometimes *AMAZED* which things get overlooked. Yes, EAGAIN is an issue. We've seen that on Solaris and AIX quite often and cursed a lot because realtime signals were unreliable prior to this patch. > > - If --norepeat is active kill(1) will properly report |EAGAIN| as > error message. Previously it reported "No such process" in such cases > which was *infuriatingly* misleading (and send a couple of > Solaris+Linux people to a "wild goose chase" to check for kernel > bugs). Nit: Is there *ever* a reason to use --norepeat? > > - kill(1) now has a -Q option to pass an address to |sigqueue()| Good The patch looks good in general except these nits: - kill --help misses some spaces - A NOTES section explaining that the number of realtime signals is flexible might be good - I dislike the abuse of Shell_t as dumping ground for everything. This includes sigval_t. Could you find a better way, e.g. pass it as parameter? - IMO Shell_t needs to be cleaned up a lot. Its an unstructured, unclean mess, IMO only second to the jobs variable in terms of being a source of possible bugs and confusion. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
