cc: [email protected] Subject: Re: Re: Re: [ast-developers] [patch] kill(1) |sigqueue()| fixes+|EAGAIN| handling etc. ... / was: Re: |sigqueue()| fixes+|EAGAIN| handling etc. ... --------
Here is how I am planning to handle the sigqueue patch: > > > 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. The -q option will be able to take integers as large as ptrdiff_t as options so that addresses can be passed, for example -q 0xffff1234. This will show up as .sh.value=4294906420. > 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. > EINTR will cause a retry > unless trapnote has pending trap or signal to process in which > case kill will fail. sigqueue will yield and return -2 for EAGAIN. Users can issue retries. > > 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. kill -q will not send SIGCONT. kill without -q will. Let me know if this is sufficient or why it is not. David Korn [email protected] _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
