Discussion:
[Gc] [PATCH] define HANDLE_FORK on unix platforms with pthreads
(too old to reply)
Andy Wingo
2012-02-17 10:08:20 UTC
Permalink
Hi,

The attached patch enables HANDLE_FORK on UNIX platforms with pthreads.
I think it's important to enable by default because in situations where
you have a shared libgc, built by a third party, you need the most
robust configuration by default.

Regards,

Andy
Andy Wingo
2012-02-17 10:05:36 UTC
Permalink
* include/private/gcconfig.h (HANDLE_FORK): Define this flag on
unix-like systems with pthread threading enabled.
---
include/private/gcconfig.h | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/include/private/gcconfig.h b/include/private/gcconfig.h
index 2293583..d402d2b 100644
--- a/include/private/gcconfig.h
+++ b/include/private/gcconfig.h
@@ -2573,6 +2573,15 @@
# define IF_CANCEL(x) /* empty */
#endif

+#if defined(UNIX_LIKE) && defined(THREADS) && defined(GC_PTHREADS) \
+ && !defined(NO_HANDLE_FORK)
+ /* Attempts to make GC_malloc() work in a child process fork()'ed */
+ /* from a multithreaded parent. Currently only supported by */
+ /* pthread_support.c. (Similar code should work on Solaris or Irix, */
+ /* but it hasn't been tried.) */
+# define HANDLE_FORK
+#endif
+
#if !defined(USE_MARK_BITS) && !defined(USE_MARK_BYTES) \
&& defined(PARALLEL_MARK)
/* Minimize compare-and-swap usage. */
--
1.7.9


--=-=-=
--
http://wingolog.org/

--=-=-=--
Ivan Maidanski
2012-02-17 20:45:51 UTC
Permalink
Hi Andy,

It seems you're proposing the right thing but I guess your patch could break build for some targets (there are some many Unix targets supported like xBSD, RTEMS, NaCl, Android, Darwin, DG/UX, HP/UX, Aix, Irix, Solaris... - does at least pthread_atfork exist everywhere?

Regards.
Post by Andy Wingo
Hi,
The attached patch enables HANDLE_FORK on UNIX platforms with pthreads.
I think it's important to enable by default because in situations where
you have a shared libgc, built by a third party, you need the most
robust configuration by default.
Regards,
Andy
--
http://wingolog.org/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Andy Wingo
2012-02-18 20:56:23 UTC
Permalink
Post by Ivan Maidanski
It seems you're proposing the right thing but I guess your patch could
break build for some targets (there are some many Unix targets supported
like xBSD, RTEMS, NaCl, Android, Darwin, DG/UX, HP/UX, Aix, Irix,
Solaris... - does at least pthread_atfork exist everywhere?
I don't know. It's from the SUSV2 standard, released in 1997. I would
think it's fairly portable, but I really don't know. The bigger problem
is that that part of libgc probably isn't as tested. It does seem to be
the right thing, though -- as much as there can be a right thing, when
you are combining threads, gc, and fork() ;-)

If we want to restrict this to e.g. glibc targets, that's fine; though,
there is no inherent reason why this couldn't work on other POSIX
platforms as well.

Regards,

Andy
--
http://wingolog.org/
Ivan Maidanski
2012-02-19 05:26:09 UTC
Permalink
Hi Andy,

Yes, you're right.
I'll try at least to check presence of pthread_atfork in various mentioned systems next week.

Regards.
Post by Andy Wingo
Post by Ivan Maidanski
It seems you're proposing the right thing but I guess your patch could
break build for some targets (there are some many Unix targets supported
like xBSD, RTEMS, NaCl, Android, Darwin, DG/UX, HP/UX, Aix, Irix,
Solaris... - does at least pthread_atfork exist everywhere?
I don't know. It's from the SUSV2 standard, released in 1997. I would
think it's fairly portable, but I really don't know. The bigger problem
is that that part of libgc probably isn't as tested. It does seem to be
the right thing, though -- as much as there can be a right thing, when
you are combining threads, gc, and fork() ;-)
If we want to restrict this to e.g. glibc targets, that's fine; though,
there is no inherent reason why this couldn't work on other POSIX
platforms as well.
Regards,
Andy
--
http://wingolog.org/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Richard O'Keefe
2012-02-19 23:38:04 UTC
Permalink
Post by Ivan Maidanski
It seems you're proposing the right thing but I guess your patch could
break build for some targets (there are some many Unix targets supported
like xBSD, RTEMS, NaCl, Android, Darwin, DG/UX, HP/UX, Aix, Irix,
Solaris... - does at least pthread_atfork exist everywhere?
pthread_atfork was in Solaris 2.10 (which I'm still using) and of course
remains in OpenSolaris (and its forks) and Solaris 2.11. It's also in
Mac OS X 10.6. According to a compatibility list I've been building,
it's in Linux 2.6 and OpenBSD 4.7, and HP-UX 11i. I have some AIX manuals
but haven't integrated those yet, sorry.
Ivan Maidanski
2012-02-20 06:15:41 UTC
Permalink
Hi Richard,

Thank you for the information.

Regards.
Post by Richard O'Keefe
Post by Ivan Maidanski
It seems you're proposing the right thing but I guess your patch could
break build for some targets (there are some many Unix targets supported
like xBSD, RTEMS, NaCl, Android, Darwin, DG/UX, HP/UX, Aix, Irix,
Solaris... - does at least pthread_atfork exist everywhere?
pthread_atfork was in Solaris 2.10 (which I'm still using) and of course
remains in OpenSolaris (and its forks) and Solaris 2.11. It's also in
Mac OS X 10.6. According to a compatibility list I've been building,
it's in Linux 2.6 and OpenBSD 4.7, and HP-UX 11i. I have some AIX manuals
but haven't integrated those yet, sorry.
Ivan Maidanski
2012-02-20 18:21:31 UTC
Permalink
Hi Andy,

1. I've committed your patch to master with some modifications. I suppose this patch should be committed to "release" branch.

2. Also, I've added a check for pthread_atfork returned value.

3. I think fork-related code should be added to Cygwin (I've not tested it yet).

4. And, slightly related to the topic, I've discovered GC_unregister_my_thread and GC_thread_exit_proc for Win32 lack GC_wait_for_gc_completion call - seems to me it is not correct.

Regards.
Post by Ivan Maidanski
Hi Richard,
Thank you for the information.
Regards.
Post by Richard O'Keefe
Post by Ivan Maidanski
It seems you're proposing the right thing but I guess your patch could
break build for some targets (there are some many Unix targets supported
like xBSD, RTEMS, NaCl, Android, Darwin, DG/UX, HP/UX, Aix, Irix,
Solaris... - does at least pthread_atfork exist everywhere?
pthread_atfork was in Solaris 2.10 (which I'm still using) and of course
remains in OpenSolaris (and its forks) and Solaris 2.11. It's also in
Mac OS X 10.6. According to a compatibility list I've been building,
it's in Linux 2.6 and OpenBSD 4.7, and HP-UX 11i. I have some AIX manuals
but haven't integrated those yet, sorry.
Andy Wingo
2012-02-20 21:26:54 UTC
Permalink
Post by Ivan Maidanski
1. I've committed your patch to master with some modifications. I
suppose this patch should be committed to "release" branch.
Excellent, thanks. I didn't even think to check if pthread_atfork had a
return value. I'm not knowledgeable about Win32 or Cygwin, so I have no
comments there.

Cheers,

Andy
--
http://wingolog.org/
Boehm, Hans
2012-02-20 23:16:28 UTC
Permalink
Sorry for not replying earlier.

I believe the reason this was not enabled by default is that Posix doesn't allow calling memory allocation functions such as malloc() between fork and exec either. Thus AFAIK, this is a workaround for a problem not introduced by the garbage collector.

It may still be a good idea to turn it on. I don't know whether glibc and malloc implementations normally try to handle this case correctly for standard malloc. If they do, we probably we should as well. But Posix-conforming code shouldn't rely on this one way or the other.

Hans
-----Original Message-----
On Behalf Of Andy Wingo
Sent: Monday, February 20, 2012 1:27 PM
To: Ivan Maidanski
Cc: gc; Richard O'Keefe
Subject: Re: [Gc] [PATCH] define HANDLE_FORK on unix platforms with
pthreads
Post by Ivan Maidanski
1. I've committed your patch to master with some modifications. I
suppose this patch should be committed to "release" branch.
Excellent, thanks. I didn't even think to check if pthread_atfork had a
return value. I'm not knowledgeable about Win32 or Cygwin, so I have no
comments there.
Cheers,
Andy
--
http://wingolog.org/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Andy Wingo
2012-02-21 09:36:04 UTC
Permalink
Thanks for the comments, Hans!
Post by Boehm, Hans
I believe the reason this was not enabled by default is that Posix
doesn't allow calling memory allocation functions such as malloc()
between fork and exec either. Thus AFAIK, this is a workaround for a
problem not introduced by the garbage collector.
Can you cite this? I am having a hard time finding this one.

There is the issue of fork from signal handlers, as well, but that is a
separate issue:

http://standards.ieee.org/findstds/interps/1003-1c-95_int/pasc-1003.1c-37.html
Post by Boehm, Hans
It may still be a good idea to turn it on. I don't know whether glibc
and malloc implementations normally try to handle this case correctly
for standard malloc.
It seems that glibc does install atfork handlers for a number of
things. See for example:

http://repo.or.cz/w/glibc.git/blob?f=malloc/arena.c#l218

Also see other uses of "thread_atfork" internal to glibc.

Regards,

Andy
--
http://wingolog.org/
Andy Wingo
2012-02-21 10:37:43 UTC
Permalink
Post by Andy Wingo
Post by Boehm, Hans
I believe the reason this was not enabled by default is that Posix
doesn't allow calling memory allocation functions such as malloc()
between fork and exec either. Thus AFAIK, this is a workaround for a
problem not introduced by the garbage collector.
Can you cite this? I am having a hard time finding this one.
I found it:

A process shall be created with a single thread. If a multi-threaded
process calls fork(), the new process shall contain a replica of the
calling thread and its entire address space, possibly including the
states of mutexes and other resources. Consequently, to avoid errors,
the child process may only execute async-signal-safe operations until
such time as one of the exec functions is called.

Humm, indeed.

Andy
--
http://wingolog.org/
Ivan Maidanski
2012-02-21 17:26:36 UTC
Permalink
Hi,
Post by Andy Wingo
Post by Ivan Maidanski
1. I've committed your patch to master with some modifications. I
suppose this patch should be committed to "release" branch.
Excellent, thanks. I didn't even think to check if pthread_atfork had a
return value.
Post by Ivan Maidanski
3. I think fork-related code should be added to Cygwin (I've not tested it yet).
I'm not knowledgeable about Win32 or Cygwin, so I have no
comments there.
fork() support in Cygwin turned out to be not so easy - we use Win32 API in some cases directly (e.g. to get stack boundaries) which isn't tracked by Cygwin runtime.

So, I'll leave it as-is for Cygwin.

Regards.
Post by Andy Wingo
Cheers,
Andy
--
http://wingolog.org/
Andy Wingo
2012-02-17 10:05:36 UTC
Permalink
* include/private/gcconfig.h (HANDLE_FORK): Define this flag on
unix-like systems with pthread threading enabled.
---
include/private/gcconfig.h | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/include/private/gcconfig.h b/include/private/gcconfig.h
index 2293583..d402d2b 100644
--- a/include/private/gcconfig.h
+++ b/include/private/gcconfig.h
@@ -2573,6 +2573,15 @@
# define IF_CANCEL(x) /* empty */
#endif

+#if defined(UNIX_LIKE) && defined(THREADS) && defined(GC_PTHREADS) \
+ && !defined(NO_HANDLE_FORK)
+ /* Attempts to make GC_malloc() work in a child process fork()'ed */
+ /* from a multithreaded parent. Currently only supported by */
+ /* pthread_support.c. (Similar code should work on Solaris or Irix, */
+ /* but it hasn't been tried.) */
+# define HANDLE_FORK
+#endif
+
#if !defined(USE_MARK_BITS) && !defined(USE_MARK_BYTES) \
&& defined(PARALLEL_MARK)
/* Minimize compare-and-swap usage. */
--
1.7.9


--=-=-=
--
http://wingolog.org/

--=-=-=--
Continue reading on narkive:
Loading...