Hi,
On Wed 21 Mar 2012 22:26, l...@gnu.org (Ludovic Courtès) writes:
> What about adding a big fat warning in the doc about use of
> ‘primitive-fork’ in a multi-threaded program?
> Andy Wingo skribis:
>
>> If other threads are active, I think primitive-fork should raise an
>> e
Hey!
Andy Wingo skribis:
> On Tue 27 Mar 2012 08:54, l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo skribis:
>>
>>> On Wed 21 Mar 2012 22:26, l...@gnu.org (Ludovic Courtès) writes:
>>>
What about adding a big fat warning in the doc about use of
‘primitive-fork’ in a multi-thre
Heya :)
An ongoing discussion...
On Tue 27 Mar 2012 08:54, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo skribis:
>
>> On Wed 21 Mar 2012 22:26, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> What about adding a big fat warning in the doc about use of
>>> ‘primitive-fork’ in a multi-thread
Hi,
Andy Wingo skribis:
> On Wed 21 Mar 2012 22:26, l...@gnu.org (Ludovic Courtès) writes:
[...]
>> Yes, things like ‘open-process’ make sense.
>>
>> What about adding a big fat warning in the doc about use of
>> ‘primitive-fork’ in a multi-threaded program?
>
> Sure. WDYT about a warning at
Hi :)
On Wed 21 Mar 2012 22:26, l...@gnu.org (Ludovic Courtès) writes:
> Without exposing ‘pthread_atfork’, how would you suggest making user
> code “fork-safe”? A use case would be reviving the futures thread pool
> after ‘fork’.
Humm, just tried to think about it for 10 minutes or so and I'm
you suggest making user
> code “fork-safe”? A use case would be reviving the futures thread pool
> after ‘fork’.
>
> > Did you see that I merged the atfork bits into master?
> > (wip-threads-and-fork also had some CLOEXEC bits that needed more
> > baking). They worked..
‘fork’.
> Did you see that I merged the atfork bits into master?
> (wip-threads-and-fork also had some CLOEXEC bits that needed more
> baking). They worked... sorta. They had a few problems:
>
> 1) It's impossible to work around the lack of atfork() in libraries
> tha
On Sat 03 Mar 2012 22:20, l...@gnu.org (Ludovic Courtès) writes:
> I’d prefer a solution where libguile-internal threads and locks are
> suitably handled upon fork (basically what wip-threads-and-fork does),
> and where users are provided with mechanisms to do the same at their
>
Hey!
Andy Wingo skribis:
> How do you feel about raising an error if primitive-fork is called, and
> there are other threads running?
I think I’d prefer a solution where libguile-internal threads and locks
are suitably handled upon fork (basically what wip-threads-and-fork
does), and
Hello :)
On Thu 01 Mar 2012 20:35, l...@gnu.org (Ludovic Courtès) writes:
> I still think that saying that “a guile built with threads […] should
> not call primitive-fork” is too strong, because again, it’s very, very
> unlikely to fail when (= 1 (length (all-threads))), GNU/Linux or not.
OK, a
Hi,
Andy Wingo skribis:
> On Sun 26 Feb 2012 23:03, l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo skribis:
>>
>>> + if (scm_ilength (scm_all_threads ()) != 1)
>>> +/* Other threads may be holding on to resources that Guile needs --
>>> + it is not safe to permit
y
unlikely to fail when (= 1 (length (all-threads))), GNU/Linux or not.
Let’s not scare our users more than necessary. ;-)
And perhaps it can be fixed in 2.0 based on what ‘wip-threads-and-fork’
provides, as discussed in another message.
Thanks,
Ludo’.
Hi!
Andy Wingo skribis:
> The solution is, besides just avoiding fork() and threads, to take locks
> on all interesting data structures when you fork(). Fortunately there
> are not too many, and most locks are not nested, so it seems to be a
> doable thing. In wip-threads-and-for
On Sun 26 Feb 2012 23:03, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo skribis:
>
>> + if (scm_ilength (scm_all_threads ()) != 1)
>> +/* Other threads may be holding on to resources that Guile needs --
>> + it is not safe to permit one thread to fork while others are
Hi,
On Sun 26 Feb 2012 23:00, l...@gnu.org (Ludovic Courtès) writes:
>> A guile built without
>> threads may fork to its heart's content. However a guile built with
>> threads -- the default, recommended configuration -- should not call
>> primitive-fork.
>
> That’s a strong statement.
Don't sh
Hi,
Andy Wingo skribis:
> + if (scm_ilength (scm_all_threads ()) != 1)
> +/* Other threads may be holding on to resources that Guile needs --
> + it is not safe to permit one thread to fork while others are
> + running.
> +
> + In addition, POSIX cl
Hi,
Andy Wingo skribis:
> A guile built without
> threads may fork to its heart's content. However a guile built with
> threads -- the default, recommended configuration -- should not call
> primitive-fork.
That’s a strong statement. When the only threads are the main thread
and the signal th
On Sun, Feb 26, 2012 at 2:01 AM, Andy Wingo wrote:
> Hi!
>
> On Sat 25 Feb 2012 03:30, Nala Ginrut writes:
>
> > 'primitive-fork' shouldn't be removed directly according to
> > previous discussion, unless the user chosen ptheads. If they do not
> > use threads, then primitive-fork would be usefu
Hi!
On Sat 25 Feb 2012 03:30, Nala Ginrut writes:
> 'primitive-fork' shouldn't be removed directly according to
> previous discussion, unless the user chosen ptheads. If they do not
> use threads, then primitive-fork would be useful, is that right?
Indeed. In Guile master, primitive-fork is
On Sat, Feb 25, 2012 at 10:21 AM, Nala Ginrut wrote:
>
>
> On Sat, Feb 25, 2012 at 2:57 AM, Andy Wingo wrote:
>
>> Hello :)
>>
>> On Fri 24 Feb 2012 04:00, Nala Ginrut writes:
>>
>> > I think I could use pipes to handle some sub-process rather than do it
>> > with fork manually. But I must crea
On Sat, Feb 25, 2012 at 2:57 AM, Andy Wingo wrote:
> Hello :)
>
> On Fri 24 Feb 2012 04:00, Nala Ginrut writes:
>
> > I think I could use pipes to handle some sub-process rather than do it
> > with fork manually. But I must create a daemon, it can't avoid to use
> > fork, will this circumstance
Hello :)
On Fri 24 Feb 2012 04:00, Nala Ginrut writes:
> I think I could use pipes to handle some sub-process rather than do it
> with fork manually. But I must create a daemon, it can't avoid to use
> fork, will this circumstance cause problems if I use threads after it?
Hummm. Very good ques
On Fri, Feb 24, 2012 at 10:47 PM, Andy Wingo wrote:
> Hi,
>
> Thanks for the feedback :)
>
> On Fri 24 Feb 2012 15:08, Nala Ginrut writes:
>
> > Considering the new 'open-process' hasn't been done, the issues left
> > suspending.
>
> Maybe I have not expressed myself well. To be clear, the new
Hi,
Thanks for the feedback :)
On Fri 24 Feb 2012 15:08, Nala Ginrut writes:
> Considering the new 'open-process' hasn't been done, the issues left
> suspending.
Maybe I have not expressed myself well. To be clear, the new
open-process implementation is now in both master and 2.0, though not
On Fri, Feb 24, 2012 at 6:21 PM, Andy Wingo wrote:
> On Fri 24 Feb 2012 04:00, Nala Ginrut writes:
>
> > I think I could use pipes to handle some sub-process rather than do it
> > with fork manually. But I must create a daemon, it can't avoid to use
> > fork, will this circumstance cause problem
On Fri 24 Feb 2012 04:00, Nala Ginrut writes:
> I think I could use pipes to handle some sub-process rather than do it
> with fork manually. But I must create a daemon, it can't avoid to use
> fork, will this circumstance cause problems if I use threads after it?
I just pushed a patch like this:
On Fri, Feb 24, 2012 at 12:13 AM, Andy Wingo wrote:
> On Thu 23 Feb 2012 16:49, Nala Ginrut writes:
>
> > I just want to do my negative vote when I saw "choose thead then fork
> > die", but I see "open-process" soon. ;-) So, what's the difference
> > between "primitive-fork" and "open-process"?
On Thu 23 Feb 2012 16:49, Nala Ginrut writes:
> I just want to do my negative vote when I saw "choose thead then fork
> die", but I see "open-process" soon. ;-) So, what's the difference
> between "primitive-fork" and "open-process"? If they're different, I
> think much code to be modified for m
On Thu, Feb 23, 2012 at 11:05 PM, Andy Wingo wrote:
> On Wed 22 Feb 2012 22:40, Andy Wingo writes:
>
> > Obviously we can treat the limited case of (ice-9 popen) in a more
> > portable fashion.
>
> I have now rewritten open-process from ice-9 popen in C, so as to be
> sure that only async-signal
On Wed 22 Feb 2012 22:40, Andy Wingo writes:
> Obviously we can treat the limited case of (ice-9 popen) in a more
> portable fashion.
I have now rewritten open-process from ice-9 popen in C, so as to be
sure that only async-signal-safe routines get called. This should make
ice-9 popen work reli
Hi all,
An update on this issue. For context:
On Wed 08 Feb 2012 23:10, Andy Wingo writes:
> I was testing out the threaded web server and it was working well. Then
> I tried it out with tekuti, a blog engine that uses git as the backend.
> It uses (ice-9 popen) to talk to the git binaries.
fork() and threads, to take locks
on all interesting data structures when you fork(). Fortunately there
are not too many, and most locks are not nested, so it seems to be a
doable thing. In wip-threads-and-fork, I added a scm_c_atfork interface
to define functions to call before and after a fork
32 matches
Mail list logo
