On 30 August 2013 04:04, Cedric Blancher <[email protected]> wrote: > 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.
Roland, could you update your patch for ast-ksh.20130829, with #ifdef for kill -Q in case David doesn't wish to integrate it, please? Ced -- Cedric Blancher <[email protected]> Institute Pasteur _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
