Question about libjava/childproc.c
thomas.stuefe at gmail.com
Tue Sep 11 17:34:02 UTC 2018
Hi Martin, Alan,
On Sun, Sep 9, 2018 at 2:34 AM, Martin Buchholz <martinrb at google.com> wrote:
> On Wed, Sep 5, 2018 at 11:43 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
>> On Wed, Sep 5, 2018 at 6:43 PM, Martin Buchholz <martinrb at google.com>
>> > So before the readdir loop we should set errno to 0. Then when readdir
>> > returns NULL, we should check whether errno is non-zero.
>> Note that if we fix this, we may run into errors which were hidden
>> before, namely if we really accidentally did close the file descriptor
>> used by opendir(). Currently, even if some file descriptors remain
>> unclosed, that may not necessarily lead to an error. But with your
>> suggested error handling we would straight away fail.
>> Therefore I would combine both fixes - add readdir error handling and
>> also change to fcntl(FD_CLOEXEC).
> I support this plan. We expect most file descriptors to already have the
> FD_CLOEXEC flag set, so a useful optimization is to set the flag only when
> not already set.
> Probably the code should be conditional on defined(FD_CLOEXEC).
Great. I just posted an RFR.
>> > ---
>> > We do have a way of reporting errno to the parent. See
>> > WhyCantJohnnyExec.
>> Ah I see.
>> Btw, do you know what happens when we modify errno in a vforked child
>> process? Would that not modify errno in the parent process too? (errno
>> is probably implemented as thread local variable, and since the parent
>> thread sleeps until we exec this may still be okay, or?).
> It's a good question. vfork is typically underspecified, so it is plausible
> that changing errno in the child affects the parent. I think we should
> simply make sure that the parent code is robust against this (as it
> typically is - you check errno when a system API has already returned an
> indication of an error)
This whole vfork thing is a rabbit hole. I spent some time with it and
will post the results in a separate mail.
As for errno, it gets actually propagated to the parent - but since
the parent forking thread is waiting in vfork, it will return from
vfork and then it just does not care (since vfork was successful there
is no reason to look at errno).
Its actually funny. Cool way to do IPC :)
>> A bit more background, if you are interested:
>> A long time ago, at SAP we swapped Oracle's implementation of
>> Runtime.exec on Unix against a completely homegrown one. The reason
>> was that we needed a really robust implementation for our customers,
>> and with the then current implementation we kept running into
>> limitations and pathological corner cases. Especially on outlier
>> platforms like HPUX or AS/400.
>> This was long before OpenJDK existed, so there was no way for us to
>> just fix the coding upstream.
> In 2005 I was the primary maintainer of the subprocess code at Sun, and
> there is a good chance you could have gotten changes in if you had asked me!
:( How often I wished I could talk to someone about stuff like this.
But well, here we are. Thank god for Open Source.
More information about the core-libs-dev