[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: Fri, 30 Sep 2011 10:05:49 -0601

On Fri, Sep 30, 2011 at 09:30:13AM +0100, Alaric Snell-Pym wrote:
> Your other points about multiple signals sugget it should be a proper
> queue, not just a bitmask. Although I have a vague feeling that Unix was
> allowed to coalesce pending signals as it just used a bitmask itself...
> Meh, I dunno, I only look into signal handling occasionally!

I was misremembering a statement from APUE (Advanced Programming in
the Unix Environment), which talks about signal queuing being
*permitted* by Posix, but not required.  And no one does it.
A test program on *BSD confirms that this operating system does not,
and Linux likely follows.  So we don't need that queue--I think I
managed to see Chicken drop one signal testing last night, but I've
not confirmed this yet and it wouldn't be a crisis should it
actually do so.  I haven't tried a more complex case I think Chicken
does suffer from, which is near-arrival of two separate signals.

At any rate, my suggestion of a signal queue was based on an
incorrect understanding of the signal mechanism and I withdraw it.

> > And that we also *must* handle
> > deferred signals before making another syscall, whether that syscall
> > happened from user code or whether we're making a syscall in service
> > to the need of the runtime.
> The one tricky case I can think of is when the chicken signal handler
> needs more RAM (so the GC is invoked) and the GC needs to malloc things
> in the heap and the heap needs to grow, so a mmap (which is what sbrk
> seems to be called these days) occurs... Do you need it run before ALL
> syscalls, or just ones that might block on something the signal handler
> might be needed to relieve? AIUI mmap of /dev/zero (to allocate more
> empty heap) can't block on very much...

I'm currently hoping that it can be run just before the ones that
block, which is an astute observation, thank you.  I'll probably
need to sit down with the signals one-by-one to be sure, but I
think this "weaker" constraint is fully correct.

> > I think is a fantastic outline of what needs to happen.  I will work on
> > a patch, with no guarantee of how fast I will be.
> Tell me if I can help - I want to gain a deeper understanding of the
> Chicken scheduler!

Thank you!

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

reply via email to

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