caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: david.baelde@ens-lyon.org
Cc: Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] Freezing
Date: Tue, 23 May 2006 13:03:51 +1000	[thread overview]
Message-ID: <1148353431.19894.19.camel@rosella.wigram> (raw)
In-Reply-To: <53c655920605221704r5ff97fdfj1fa953f6f858a8b1@mail.gmail.com>

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
process.

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++: http://felix.sf.net


  reply	other threads:[~2006-05-23  3:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-23  0:04 Freezing David Baelde
2006-05-23  3:03 ` skaller [this message]
2006-05-23 13:24   ` [Caml-list] Freezing Eric Cooper
2006-05-24 15:51   ` David Baelde

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=1148353431.19894.19.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=david.baelde@ens-lyon.org \
    /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 NNTP newsgroup(s).