Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-05-23 (03:04)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Freezing
On Tue, 2006-05-23 at 02:04 +0200, David Baelde wrote:

> <<<
> flush_all () ;
> let pid = Unix.fork () in
> if pid = 0 then begin
>   ignore (Unix.alarm 20) ;
>   Fetch.cp there here ;
>   exit 0
> end else
>   Unix.waitpid [] pid
> >>>

> The main process is threaded but the child isn't. Isn't it weird that
> it gets blocked in such a way ? 

When you fork() a process the whole memory space of the parent 
is cloned, including locks, file handles, buffers, etc -- including
those being used by threads other than the one doing the fork().

So now you can have this: some thread of the parent
is doing I/O and acquires a lock, you fork, then the
buffer is written, pointers into it adjusted,
and the lock is released.

When the forked() process tries to terminate ..
the lock is locked because it is a copy of the original
lock. And the buffer pointers say the buffer is full.
So the process hangs waiting for the lock to be released
and the buffer to be emptied by a thread that has
already done so .. but the state saying that
is in the original address space, not that of the

The moral is -- use threads or processes but not both
together, Unix can't handle it. 

John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: