On 7 September 2013 14:04, Irek Szczesniak <[email protected]> wrote: > 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? >
We talked this through on today's engineering meeting. We agree with Irek, it is technically not possible to fill both the sival_int and sival_ptr fields of the sigval_t UNION using one option taking a single integer argument. IMHO both kill -q and kill -Q are required to independently fill either sival_int and sival_ptr, and have the .sh.sig.value.int and .sh.sig.value.ptr fields as counterparts to obtain the value. I've been myself doubtful of the usefulness of kill -Q, but my staff pointed out that in any case the shell needs .sh.sig.value.ptr because a sender - which might necessarily not be a ksh93 script - can use sival_ptr instead of sival_int to pass data to the shell and sival_int cannot be used to substitute sival_ptr, neither can sival_ptr be used to substitute sival_int. kill -Q comes handy to pass larger data or object references around, or (important!) forward received information (signal proxy), so it might be good to have this option. Lionel _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
