public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Ken Brown <kbrown@cornell.edu>
Cc: cygwin@cygwin.com
Subject: Re: Synchronization problem with posix_spawn
Date: Thu, 30 Jul 2020 19:17:23 +0200	[thread overview]
Message-ID: <20200730171723.GA460314@calimero.vinschen.de> (raw)
In-Reply-To: <20200730115913.GL4206@calimero.vinschen.de>

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?


Thanks,
Corinna


diff --git a/newlib/libc/posix/posix_spawn.c b/newlib/libc/posix/posix_spawn.c
index 19c5cd0fe986..3adbac29d7fd 100644
--- a/newlib/libc/posix/posix_spawn.c
+++ b/newlib/libc/posix/posix_spawn.c
@@ -254,6 +254,82 @@ process_file_actions(const posix_spawn_file_actions_t fa)
 	return (0);
 }
 
+#ifdef __CYGWIN__
+#include <windows.h>
+#include <sys/mman.h>
+#include <process.h>
+
+typedef struct
+{
+  pid_t pid;
+  int error;
+} child_info;
+
+static int
+do_posix_spawn(pid_t *pid, const char *path,
+	const posix_spawn_file_actions_t *fa,
+	const posix_spawnattr_t *sa,
+	char * const argv[], char * const envp[], int use_env_path)
+{
+	pid_t p;
+	int ret = 0;
+	child_info *ci;
+
+	ci = (child_info *) mmap(NULL, sizeof(child_info),
+				 PROT_READ | PROT_WRITE,
+				 MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+	if (ci == MAP_FAILED)
+		return (errno);
+
+	/* Cygwin's vfork does not follow BSD vfork semantics.  Rather it's
+	   equivalent to fork.  While that's POSIX compliant, it means the
+	   below FreeBSD implementation relying on BSD vfork semantics
+	   doesn't work as expected on Cygwin. */
+	p = fork();
+	switch (p) {
+	case -1:
+		ret = errno;
+		break;
+	case 0:
+		if (sa != NULL) {
+			ci->error = process_spawnattr(*sa);
+			if (ci->error)
+				_exit(127);
+		}
+		if (fa != NULL) {
+			ci->error = process_file_actions(*fa);
+			if (ci->error)
+				_exit(127);
+		}
+		if (use_env_path)
+			p = spawnvpe(_P_NOWAITO, path,
+				     (const char * const *) argv,
+				     (const char * const *)
+				     (envp != NULL ? envp : *p_environ));
+		else
+			p = spawnve(_P_NOWAITO, path,
+				    (const char * const *) argv,
+				    (const char * const *)
+				    (envp != NULL ? envp : *p_environ));
+		if (p < 0) {
+			ci->error = errno;
+			_exit(127);
+		}
+		ci->pid = p;
+		_exit (0);
+	default:
+		if (waitpid(p, NULL, 0) < 0)
+			ret = errno;
+		else if (ci->error)
+			ret = ci->error;
+		else if (pid != NULL)
+			*pid = ci->pid;
+		break;
+	}
+	munmap(ci, sizeof(child_info));
+	return ret;
+}
+#else
 static int
 do_posix_spawn(pid_t *pid, const char *path,
 	const posix_spawn_file_actions_t *fa,
@@ -292,6 +368,7 @@ do_posix_spawn(pid_t *pid, const char *path,
 		return (error);
 	}
 }
+#endif
 
 int
 posix_spawn (pid_t *pid,

-- 
Corinna Vinschen
Cygwin Maintainer

  reply	other threads:[~2020-07-30 17:17 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 [this message]
2020-07-30 23:04       ` Ken Brown
2020-07-31  8:10         ` Corinna Vinschen
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=20200730171723.GA460314@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    --cc=kbrown@cornell.edu \
    /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).