This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: extending wait4(2) or waitid(2) linux syscall


On November 28, 2018 10:31:23 PM GMT+13:00, Florian Weimer <fweimer@redhat.com> wrote:
>* Arnd Bergmann:
>
>> On Mon, Nov 26, 2018 at 4:18 PM Florian Weimer <fweimer@redhat.com>
>wrote:
>>>
>>> * Arnd Bergmann:
>>>
>>> > On Thu, Nov 15, 2018 at 7:30 AM Dmitry V. Levin <ldv@altlinux.org>
>wrote:
>>> >> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
>>> >> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
>>> >> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD
>wrote:
>>> >>
>>> >> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
>>> >> with a different signal mask, this cannot be achieved without
>>> >> an extended version of syscall, similar to pselect6(2) extension
>>> >> over select(2) and ppoll(2) extension over poll(2).
>>> >>
>>> >> Signal mask specification in linux requires two parameters:
>>> >> "const sigset_t *sigmask" and "size_t sigsetsize".
>>> >> Creating pwait6(2) as an extension of wait4(2) with two arguments
>>> >> is straightforward.
>>> >> Creating pwaitid(2) as an extension of waitid(2) that already has
>5
>>> >> arguments would require an indirection similar to pselect6(2).
>>> >
>>> > Getting back to this point: you could also do the same thing with
>>> > the CLONE_FD approach from Josh Triplett[1] or Casey Dahlin's
>>> > older waitfd() syscall, correct?
>>>
>>> A descriptor-based solution would not be useful to glibc because
>>> applications assume that glibc does not (persistently) open any file
>>> descriptors behind t heir back.
>>
>> Right, makes sense. What about a temporary file descriptor as
>discussed
>> in the recent procfd() mail thread then? Would that work?

The intention has always been to start a
file descriptor process API off of that.
If we land my procfd_signal() patchset we are in good shape for procfd_wait(), imho.

>>
>> /* for illustration, needs error handling and more features */
>> int pwait(pid_t id, siginfo_t *infop)
>> {
>>       char waitfd_file[MAX_PROCFD_LEN];
>>       struct pollfd pfd[1] = { {.events = POLLIN }};
>>
>>       snprintf(waitfd_file, MAX_PROCFD_LEN, "/proc/%d/wait", pid);
>>       pfd.fd = open(waitfd_file,  O_RDONLY);
>>       ppoll(&pfd, 1, NULL, sigmask);
>>       read(fd, infop, sizeof(*infop));
>>       close(fd);
>>
>>      return 0;
>> }
>
>Together with an officiall supported way that allows us that the
>process
>denoted by the PID is still the same that it was, it could work, I
>think.
>
>It would also nice to have the ability to launch processes without
>making them visible to wait, and trigger SIGCHLD signals, but noticing
>process exit seems like a tricky matter under these circumstances.
>
>Thanks,
>Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]