From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Synchronization problem with posix_spawn
Date: Fri, 31 Jul 2020 10:10:25 +0200 [thread overview]
Message-ID: <20200731081025.GB460314@calimero.vinschen.de> (raw)
In-Reply-To: <86051625-646d-065a-8543-1c3086411d3d@cornell.edu>
On Jul 30 19:04, Ken Brown via Cygwin wrote:
> Hi Corinna,
>
> On 7/30/2020 1:17 PM, Corinna Vinschen wrote:
> > Hi Ken,
> >
> > On Jul 30 13:59, Corinna Vinschen wrote:
> > > On Jul 29 19:12, Ken Brown via Cygwin wrote:
> > > > On 7/29/2020 4:17 PM, Ken Brown via Cygwin wrote:
> > > > > posix_spawn(p) returns before the spawned process is fully up and
> > > > > running. [...]
> > > > I just took a look at the source, and I see that posix_spawn was taken from
> > > > FreeBSD. Does FreeBSD have the same problem? Should applications just be
> > > > aware of this issue and insert a sleep after posix_spawn before sending
> > > > signals?
> > >
> > > Actually, this is a Cygwin problem. I just had a look into the
> > > newlib implementation myself, and it turns out that the code,
> > > in particular the do_posix_spawn() function, is BSD specific. It
> > > relies on the BSD implementation of vfork(2). Cygwin's vfork(2)
> > > on the other hand, is NOT following the historic idea of the
> > > BSD vfork(2), rather it's equivalent to fork(2). This is
> > > POSIX compliant, but certainly the reliance of the BSD vfork
> > > behaviour makes do_posix_spawn() as it's implemented right now,
> > > not overly functional for Cygwin.
> > >
> > > IOW, we need a Cygwin-specific do_posix_spawn() using fork(2)
> > > in conjunction with some synchronization the BSD function
> > > gets "for free" by using its specific vfork(2).
> >
> > Below is a POC implementation for a Cygwin-specific do_posix_spawn().
> > If this does the trick (at least your testcase works in my testing),
> > then I'm planning to move the function over to the winsup/cygwin dir
> > so it can be streamlined further.
> >
> > Can you give it a try?
>
> It looks like something further is needed: 'wait' doesn't seem to recognize
> the spawned process.
Oh well. I did a quick test with your new testcase (thanks for that!)
and it seems to be a bit more complicated than I anticipated yesterday.
The parent-child relationship between the processes is broken. I have
to think a while about this problem, stay tuned.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
next prev parent reply other threads:[~2020-07-31 8:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 20:17 Ken Brown
2020-07-29 23:12 ` Ken Brown
2020-07-30 11:59 ` Corinna Vinschen
2020-07-30 17:17 ` Corinna Vinschen
2020-07-30 23:04 ` Ken Brown
2020-07-31 8:10 ` Corinna Vinschen [this message]
2020-08-03 9:10 ` Peter Dons Tychsen
2020-08-03 10:50 ` Corinna Vinschen
2020-08-20 5:40 ` Peter Dons Tychsen
2020-08-20 12:50 ` Corinna Vinschen
2020-08-21 7:58 ` Peter Dons Tychsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200731081025.GB460314@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).