I think you can test this theory with this patch. If a thread is waiting
on the task-cond condition variable which is matched up with task-lock,
then pthread_cond_destroy will return EBUSY, which must always be a bug in
the RTS.
Alexander
diff --git a/rts/posix/OSThreads.c
Or this. It seems that you must compile with DEBUG for the mutex check.
This enables error-checking mutexes on posix.
Alexander
diff --git a/rts/posix/OSThreads.c b/rts/posix/OSThreads.c
index ae31966..e07221d 100644
--- a/rts/posix/OSThreads.c
+++ b/rts/posix/OSThreads.c
@@ -91,7 +91,8 @@
] forkProcess, forkIO, and multithreaded runtime
Sorry to be reviving this thread so long after but I seem to be running
into similar issues as Michael S. did at the start.
In short, I'm using forkProcess with the threaded RTS, and see occasional
hangs:
* I see these only on Linux. On Mac OS X, I
a workaround
until the platform gets fixed.
Chris
From: Mark Lentczner mark.lentcz...@gmail.com
Date: Sunday, 20 January 2013 23:15
To: haskell haskell-cafe@haskell.org
Cc: Mike Meyer m...@mired.org
Subject: Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
Sorry to be reviving
Sorry to be reviving this thread so long after but I seem to be running
into similar issues as Michael S. did at the start.
In short, I'm using forkProcess with the threaded RTS, and see occasional
hangs:
- I see these only on Linux. On Mac OS X, I never do.
- I'm using GHC 7.4.2
-
I just looked at this code and since I don't know the code I can't give you
good solutions, but for others watching this thread the links might prove
interesting.
My main theory is that you do have some other thread in FFI-land while you
are fork()ing. The task-cond, task-lock seems to be
On Mon, Jan 21, 2013 at 12:15 AM, Mark Lentczner
mark.lentcz...@gmail.comwrote:
Sorry to be reviving this thread so long after but I seem to be
running into similar issues as Michael S. did at the start.
In short, I'm using forkProcess with the threaded RTS, and see occasional
hangs:
On 17 October 2012 00:17, Mike Meyer m...@mired.org wrote:
On Tue, 16 Oct 2012 21:55:44 +0200
Alexander Kjeldaas alexander.kjeld...@gmail.com wrote:
There are variants of this, but the meta-problem is that at the point in
time when you call forkProcess, you must control all threads,
On Mon, Oct 15, 2012 at 6:30 PM, Joey Hess j...@kitenet.net wrote:
Michael Snoyman wrote:
I think I have a misunderstanding of how forkProcess should be working.
Ultimately this relates to some bugs in the development version of
keter, but
I've found some behavior in a simple test program
On 15 October 2012 09:47, Michael Snoyman mich...@snoyman.com wrote:
Hi all,
I think I have a misunderstanding of how forkProcess should be working.
Ultimately this relates to some bugs in the development version of keter,
but I've found some behavior in a simple test program which I
Since we're talking about forkIO here - not forkOS - is it possible
to control the use of OS threads to avoid this problem? As I
understand it, the problem is with real OS threads. A program
running entirely in multiple `green' threads will fork to the same
set of threads in the same state,
The problems with forkProcess really are not Haskell's fault.
You will find warnings in the documentation for C's fork():
There are limits to what you can do in the child process.
To be totally safe you should restrict yourself to only
executing async-signal safe
On Tue, 16 Oct 2012 21:55:44 +0200
Alexander Kjeldaas alexander.kjeld...@gmail.com wrote:
There are variants of this, but the meta-problem is that at the point in
time when you call forkProcess, you must control all threads, ensuring that
*all invariants hold*. Thus no locks held, no thread
Hi all,
I think I have a misunderstanding of how forkProcess should be working.
Ultimately this relates to some bugs in the development version of keter,
but I've found some behavior in a simple test program which I wouldn't have
expected either, which may or may not be related.
With the program
On 15/10/2012 09:47, Michael Snoyman wrote:
With the program at the end of this email, I would expect that, once per
second, I would get a message printed from each forkIO'd green thread,
the forked process, and the master process. And if I spawn 8 or less
child threads that's precisely what
Mon, Oct 15, 2012 at 09:47:35AM +0200, Michael Snoyman wrote
Hi all,
I think I have a misunderstanding of how forkProcess should be working.
Ultimately this relates to some bugs in the development version of keter, but
I've found some behavior in a simple test program which I wouldn't have
Michael,
Having looked through the code for the process package a bit, my
initial guess is that this is being caused by a signal being sent to the child
process, but I'm not familiar enough with the inner workings to confirm or
disprove this guess.
To remove that comment for finally, you
Michael Snoyman wrote:
I think I have a misunderstanding of how forkProcess should be working.
Ultimately this relates to some bugs in the development version of keter, but
I've found some behavior in a simple test program which I wouldn't have
expected either, which may or may not be related.
On Mon, Oct 15, 2012 at 12:30 PM, Joey Hess j...@kitenet.net wrote:
forkProcess comes with a giant warning: since any other running threads
are not copied into the child process, it's easy to go wrong: e.g. by
accessing some shared resource that was held by another thread in the
My understanding is that System.Process avoids these problems by doing
all the setup around forking a command in C code. I've banished
forkProcess from my code base entirely, except for a double fork I need
to daemonize, and I don't even trust that call. :/
I think you are right. forkProcess
20 matches
Mail list logo
