[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] remove enable/disable interrupt flag

From: Alan Post
Subject: Re: [Chicken-users] remove enable/disable interrupt flag
Date: Thu, 29 Sep 2011 08:02:18 -0600

On Thu, Sep 29, 2011 at 03:43:16PM +0200, Jörg F. Wittenberger wrote:
> On Sep 29 2011, Alan Post wrote:
> >This patch removes the enable/disable interrupt flag from the
> >scheduled.
> >
> >I can't see that this code is referenced.  I'm not sure someone
> >would just write this feature for fun, however.  Is this code
> >actually used?
> Be careful!
> I found it to be win to actually reference and use that code.
> I do lot's of process-fork.  The childs will soon be replaced
> by another program.  Why should they spend time in garbage collection
> before the exec call?  Futhermore it's dangerous to leave all
> threads enabled after a fork.  I've seen cases when those subprocess
> managed to write to file descriptors used by the parent.
> That's one the the things on my list: find some better way to do
> the fork.  So far I do
> (define-foreign-variable C_interrupts_enabled bool "C_interrupts_enabled")
> (define (chicken-enable-interrupts!) (set! C_interrupts_enabled #t))
> (define chicken-disable-interrupts! (foreign-lambda void
> "C_disable_interrupts"))
> (let ((pid (begin
>  (chicken-disable-interrupts!)
>  ((foreign-lambda int "fork")) ))
> (if (not (= pid 0)) (chicken-enable-interrupts!))
> ...
> )

I figured if someone was using this, it would be you!

Thank you for this use case.  I'll account for it now.

I withdraw this patch--I do consider this code broken--including the
test case above (it has a race condition where a signal might be
delivered before the fork but after the disable interrupts), though
this is not the only case in the signal handling code where this is

I'll resubmit a new patch.

.i ma'a lo bradi cu penmi gi'e du

reply via email to

[Prev in Thread] Current Thread [Next in Thread]