Chris's Wiki :: blog/programming/ThreadsAndFork

`fork()`, `wait()`, and threads

August 22, 2006

Something I've discovered through (painful) experience is that threaded programs cannot portably fork() in one thread and then wait() for the forked process in another one.

This will work in some environments but fail explosively in others; the one I stubbed my toe on was a Linux 2.4 kernel based system (without NPTL, which is the usual state of affairs for 2.4-based Linux distributions).

Admittedly, mixing threads and fork() is a bit perverse, but sometimes it's what you need to do.

(I saw this in a Python program, but Python isn't doing anything special in the POSIX threads department so I have to expect that it's completely generic.)

Comments on this page:

By DanielMartin at 2006-08-23 09:16:47:

Are threads in Python really using the underlying OS threads? That is, I thought that threads in Python were like threads in Ruby - not using the underlying OS's threading mechanism, but instead simply relying on the interpreter keeping multiple contexts in memory and using non-blocking IO underneath.

By cks at 2006-08-23 10:31:31:

Python has a confusing thread model; Python threads are real OS threads, but the bytecode interpreter itself is single-threaded with a global lock. Code in C-level modules can release the global interpreter lock when it does various time-consuming things, including sleeping.

This is functionally similar to Ruby's model but makes it easier to work with C-level stuff that isn't based on non-blocking IO, whether it's C library functions like gethostbyname() or just significant computation.

(See also UsefulPythonThreads and WhatTheGILProtects for more in-depth rambling about this.)

Written on 22 August 2006.

«	Most new products are upgrades

Link: Csh Programming Considered Harmful

fork(), wait(), and threads

Comments on this page:

`fork()`, `wait()`, and threads