This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [PATCH RFC] fork: remove cygpid.N sharedmem on fork failure
On 06/21/2018 09:27 AM, Corinna Vinschen wrote:
> On Jun 20 17:47, Michael Haubenwallner wrote:
>> On 06/07/2018 10:19 AM, Corinna Vinschen wrote:
>>> On Jun 5 15:05, Michael Haubenwallner wrote:
>>>> Hi,
>>>>
>>>> I'm using attached patch for a while now, and orphan cygpid.N shared memory
>>>> instances are gone for otherwise completely unknown windows process ids.
>>
>> Without this patch, for the first-try child process which the
>> cygwin1.dll fails to initialize for because of wrong dll loaded,
>> the process handle is released but the cygpid.N shmem handle is not.
>>
>> Then, another completely independent process may get the same
>> windows process id again, and cygwin1.dll fails to initialize
>> because of the existing but orphaned cygpid.N shmem handle.
>
> This problem appear to be a non-problem in the normal code path.
Well, the underlying OS may temporarily be low on resources,
and the parent process may retry to fork by itself...
Currently, when the child process can be created but not initialized
by cygwin1.dll for whatever reason, the process handle is closed, but
(as far as I have understood) the shmem handle actually is lost, and
the orphaned shmem entry exists until the parent process terminates.
> In case of restarting the 2nd-try child, wouldn't it make sense to reuse
> the shmem area instead of breaking it down?
The 2nd-try child usually does get another windows pid, and we would have
to *rename* the shmem: *before* closing the 1st-try windows process handle.
And when neither child can be initialized for low resource reasons?
/haubi/