On 21 August 2013 16:09, David Korn <[email protected]> wrote: > cc: [email protected] > Subject: Re: Re: [ast-developers] [patch] kill(1) |sigqueue()| fixes+|EAGAIN| > handling etc. ... / was: Re: |sigqueue()| fixes+|EAGAIN| handling etc. ... > -------- > >> Attached (as "astksh20130814_sigqueuerepeat002.diff.txt") is a patch >> which fixes (some of) the issues listed above... > > > I read over Rolands patch and while it contains useful ideas, I have > some problems with it. > > Let me go over them piece by piece. > > 1. Add -Q to pass addresses. > Currently the shell has no way of utilizing an address so there > is no present need. Currently, the value field models the > C standard and treats value as a union. However, it could treat > the field as an integer choosing the large of void* and int as > the size and pass the value that way. I would add a typedef > for this type. It would be an integral type rather than a union. > A user could do kill -q $((0x4000abc)) or just kill -q 0x4000abc to > send a pointer since optget will convert to an integer. > Programs could format the value as an address or as an int. > I think that this needs more discussion before adding -Q. > Commands already have too many options so I am reluctant to > add an option unless necessary.
I say its necessary. I asked for this and spend quite some time and effort (11 emails) convincing Roland about having it. The arguments are: 1. Not all targets which receive signals are ksh93 2. The targets may provide a set of valid addresses to ksh93 scripts which are used to trigger actions or pass object references disguised as kill -Q $address -s RTMIN $pid 3. We are talking about "BIG DATA" (all uppercase). >= 1TB of main memory. kill -q runs out of breath at 2**31, which are 2**31 objects/actions you can pick from. -Q runs out of breath at 2**63, which is a lot more and unlikely to happen anytime soon Roland's counterarguments are: - WTF a new option? - Can't you fit this into a mapping list which maps objects to 2*31 choices? My answer: No, we can't because its cumbersome and we already have more than 2**31 objects on production systems which need to be processed in one step. - Addresses are not portable. My answer: yes, they are, but application and scripts are running on the same machine anyway. > > 2. Add -R to handle EAGAIN > I don't think that this is needed. EAGAIN should be handled > as it is with fork with an exponential back-off algorithm that > times out after around 30 seconds. What would not improve the situation as there is still the risk that this blows up in the face of the user. Either we have -R or have it not, but please don't do a stupid half fix which still keeps the risk of blowing up in the face of the user at the worst possible time. > EINTR will cause a retry > unless trapnote has pending trap or signal to process in which > case kill will fail. This isn't EINTR, this is EAGAIN > > 3. Add -C to not send SIGCONT when sending a signal. I don't > see why you would want to send a signal to a stopped process > and not have it react. I believe that C-shell (the originator > of job control) always sent SIGCONT. If there is a need for > this, I could be convinced. I think this has been answered. Processes should be able to get signals queued and not change their state from STOPPED to RUNNING. > > Let me know what you think. I'll be nice if Roland's patch could be accepted without functional changes. If there are objections please let me KNOW that I can respond. Ced -- Cedric Blancher <[email protected]> Institute Pasteur _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
