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
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
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 relat
On Mon, Jan 21, 2013 at 12:15 AM, Mark Lentczner
wrote:
> 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 on
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 b/rts/posix/OSThread
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 @@ init
on
forkProcess don't go far enough, or there is a bug needing a workaround
until the platform gets fixed.
Chris
From: Mark Lentczner
Date: Sunday, 20 January 2013 23:15
To: haskell
Cc: Mike Meyer
Subject: Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
Sorry
er the current notes on
> forkProcess don't go far enough, or there is a bug needing a workaround
> until the platform gets fixed.
>
> Chris
>
> From: Mark Lentczner
> Date: Sunday, 20 January 2013 23:15
> To: haskell
> Cc: Mike Meyer
> Subject: Re: [Haskell-caf
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 wha
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 ha
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 relat
On Mon, Oct 15, 2012 at 12:30 PM, Joey Hess 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
> parent.
>
> In my
> 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. forkProce
On Mon, Oct 15, 2012 at 6:30 PM, Joey Hess 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 which I
On 15 October 2012 09:47, 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
> expect
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, creat
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 operations
On Tue, 16 Oct 2012 21:55:44 +0200
Alexander Kjeldaas 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 is in the C library,
> no f
On 17 October 2012 00:17, Mike Meyer wrote:
> On Tue, 16 Oct 2012 21:55:44 +0200
> Alexander Kjeldaas 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*.
20 matches
Mail list logo
