Re: [PATCH v2] Cygwin: fork: Call pthread::atforkprepare() in lock_pthread()

On Thu, 28 May 2026 15:43:37 +0200 (CEST)
Johannes Schindelin wrote:
> Hi Takashi,
> 
> On Wed, 20 May 2026, Takashi Yano wrote:
> 
> > Since the commit 5f515cf3d6e3, if one thread calls fclose() while
> > another thread calls fork(), a deadlock can occur. The mechanism
> > is as follows.
> >   1) fclose() first calls __sfp_lock_acquire() and, then calls
> >      lock_process::locker.acquire() via cygheap_fdget().
> >   2) fork() first calls lock_process::locker.acuire() via the
> >      constructor of the lock_process class in the hold_everything
> >      class, and then calls __sfp_lock_acquire() via __fp_lock_all()
> >      in atforkprepare().
> >   3) As a result, the thread calling fclose() tries to acquire the
> >      lock_process lock while holding __sfp_lock, and the thread
> >      calling fork() tries to acquire __sfp_lock while holding the
> >      lock_process lock.
> > This leads to a deadlock. Before the commit 5f515cf3d6e3, __sfp_lock
> > was acquired in the constructor of the lock_pthread class in the
> > hold_everything class, and since lock_pthread is defined before
> > lock_process, this deadlock did not occur.
> > 
> > This patch moves the atforkprepare() call back into the constructor
> > of the lock_pthread class, restoring the previous lock qcquisition
> > order.
> 
> I am not super familiar with this part of the code, which is why this
> commit message is really helpful. From my point of view, this patch is
> good to go.

Pushed.

> P.S.: You may want to s/qcquisition/qcquisition/ before applying, even if
> this typo cannot harm the clarity of the commit message.

Oops! Fixed.

-- 
Takashi Yano <[email protected]>