On Tue, Sep 3, 2013 at 10:07 PM, David Korn <[email protected]> wrote: > 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.
How should this possibly work? 1. sigval_t is an *union* and not a struct. How do you decide whether the value goes into the sival_int or the sival_ptr member? You can't use them as "equal" because they have usually different sizes, i.e. sizeof(pointer) > sizeof(int) and there is no way to tell whether the si_int data occupy the low or high 32bit word of a 64bit pointer. 2. The sender and receiver must know whether they with to use si_int or si_ptr. Using one at the sender side and using the other on the receiver side is a good way to get random values. 3. You invoke the wrath of big and little endian platforms. One of them will break with your solution. 4. sival_int is a signed property, si_ptr is an unsigned property. How would you handle that? > >> 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. How can a builtin return a negative return value? >> >> 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. Sounds good. > > Let me know if this is sufficient or why it is not. Obviously using kill -q to fill both si_int and si_ptr at the same time doesn't fly. Not with the POSIX apis I know about at least. I would still favor strongly the kill -q/kill -Q approach Roland invented to choose either a) sival_int (kill -q signed_integer_value) or b) sival_ptr (kill -Q hexadecimal_value), and do the same with .sh.sig.value.int and .sh.sig.value.ptr. I know that ksh93 doesn't allow pointers, but I accept Cedric's explanation that passing an unsigned long hexadecimal value around that way is a good way to pass an "object handle" around. Also, keep in mind that not all senders and not all receivers are shell scripts. Typically realtime applications use SIGRT signals because its a reliable, low latency and allocation-free way to communicate between processes. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
