Date: Sat, 24 Jan 1998 01:05:51 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: hackers@FreeBSD.ORG Subject: pthreads implementation in 3.0 (fwd) Message-ID: <Pine.BSF.3.96.980124005636.5088g-100000@cyrus.watson.org>
next in thread | raw e-mail | index | archive | help
I sent this to questions, but it has been suggested to me that hackers may have been a preferred destination :). To quickly give an overview: many FreeBSD library calls are thread-safe. Some don't do anything about threads. Solaris has two invocations of fork -- one that follows process semantics (all threads appear in the child), and one that continues only the execution of the main thread in the child process. Under pthreads, the latter semantics is the only supported one. In the case of fork and exec, it is required. A possible implementation would be to have the threaded library fork disable threading prior to execution, then reenable threading in only the parent. Behavior of mutexes would have to be defined -- in the child, with the disabling of threading, perhaps all mutexes would be released (etc) or return the deadlock error. Thanks, Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ ---------- Forwarded message ---------- Date: Thu, 22 Jan 1998 16:42:01 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: questions@freebsd.org Subject: pthreads implementation in 3.0 Quick questions about the pthreads implementation: 1. Is there a thread-safe fork (as found in the Solaris pthreads fork() or lwp fork1()) that only copies the current thread (not the current process and all of its threads). I am working with threads and need to fork/exec another process, but current behavior duplicates all existing threads not just the one that wishes to cause another program to execute. Is there a known workaround to this? :) The Solaris fork() library call implementation claims that it is pthreads compliant; this would make ours less compliant (on the other hand, our fork does not claim to be compliant, so this might not be a problem as such.) 2. As an alternative, is there a call that can be used to suspend threading (leaving the current thread in the foreground) such that the process could fork, do it's little fork thing, then reenable threading to perform a threaded wait for the child to finish. In the mean time, the forked child would not be threading, so the rest of the threads would not be awake to cause problems. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980124005636.5088g-100000>