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,
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...
In the old days, yes. Now signals have guaranteed delivery, at least if
On Sep 30 2011, Alan Post wrote:
I think your point about signal being a wrapper around sigaction
deserves to be repeated: it's my understanding too, and means that
as it stands, my sigaction patch is essentially or completely a
no-op on most platforms. Jerry's experience with it confusingly
Alan Post scripsit:
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.
Yes. I was confusing the conventional signals with the real-time
signal
: alanp...@sunflowerriver.org
Cc: chicken-users@nongnu.org
Subject: Re: [Chicken-users] remove enable/disable interrupt flag
Sent: 30 Sep 2011 16:47
Alaric Snell-Pym scripsit:
Yeah. We need to make sure that Chicken's stack limit (which triggers a
GC) is sufficiently clear of the real stack limit
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?
I'm preparing a larger patch for the signal handling code, so
knowing whether this
On Thu, Sep 29, 2011 at 07:12:20AM -0600, 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?
I'm preparing a
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
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 02:43 PM, Jörg F. Wittenberger wrote:
(define (chicken-enable-interrupts!) (set! C_interrupts_enabled #t))
(define chicken-disable-interrupts! (foreign-lambda void
C_disable_interrupts))
(let ((pid (begin
On Sep 29 2011, Alaric Snell-Pym wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 02:43 PM, Jörg F. Wittenberger wrote:
(define (chicken-enable-interrupts!) (set! C_interrupts_enabled #t))
(define chicken-disable-interrupts! (foreign-lambda void
C_disable_interrupts))
(let
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 04:25 PM, Jörg F. Wittenberger wrote:
POSIX says that fork needs to produce only a single surviving POSIX
thread in the child. Perhaps Chicken fork needs to do the same with
Chicken threads.
Alaric, that's exactly the effect and
On Thu, Sep 29, 2011 at 04:35:04PM +0100, Alaric Snell-Pym wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 04:25 PM, Jörg F. Wittenberger wrote:
POSIX says that fork needs to produce only a single surviving POSIX
thread in the child. Perhaps Chicken fork needs to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 04:47 PM, Alan Post wrote:
The way Chicken is currently implemented, any signal that arrives
during this time is discarded, which also makes me unhappy with this
situation. A lot of blood and tears were spilled over signal
handling
On Thu, Sep 29, 2011 at 05:06:54PM +0100, Alaric Snell-Pym wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 04:47 PM, Alan Post wrote:
It seems that the thread-like nature of signal handling and the
thread-like nature of threading have been intermixed in the
scheduler,
On Sep 29 2011, Alaric Snell-Pym wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 04:25 PM, Jörg F. Wittenberger wrote:
POSIX says that fork needs to produce only a single surviving POSIX
thread in the child. Perhaps Chicken fork needs to do the same with
Chicken threads.
On Sep 29 2011, Alan Post wrote:
The way Chicken is currently implemented, any signal that arrives
during this time is discarded, which also makes me unhappy with this
Wait, I'm confused.
During which time signals are really discarded?
As far as I read the source, the signal will be
On Thu, Sep 29, 2011 at 06:56:03PM +0200, Jörg F. Wittenberger wrote:
On Sep 29 2011, Alan Post wrote:
The way Chicken is currently implemented, any signal that arrives
during this time is discarded, which also makes me unhappy with this
Wait, I'm confused.
During which time signals are
On Sep 29 2011, Alan Post wrote:
On Thu, Sep 29, 2011 at 06:56:03PM +0200, Jörg F. Wittenberger wrote:
On Sep 29 2011, Alan Post wrote:
The way Chicken is currently implemented, any signal that arrives
during this time is discarded, which also makes me unhappy with this
Wait, I'm confused.
On Thu, Sep 29, 2011 at 08:35:41PM +0200, Jörg F. Wittenberger wrote:
On Sep 29 2011, Alan Post wrote:
If a signal is called when C_interrupts_enabled is false, the signal
handler turns into a no-op.
global_signal_handler calls C_raise_interrupt, but C_raise_interrupt
does nothing if
On Sep 29 2011, Jörg F. Wittenberger wrote:
Wait, I'm confused.
Obviously I am.
I've been talking nonsense. Sorry for the confusion.
Finalizers and signal handlers are run with the same restrictions
on allocating memory.
(My confusion came from the idea in the back of my head, that I
On Sep 29 2011, Alan Post wrote:
Hence my question how to clean up the API. Default to possibly useless
re-calling the handler (while it assumes possibly having missed a signal
and hence re-check everything)? Provide a modified API which covers
both cases? ...
It may have been posted before
On Thu, Sep 29, 2011 at 10:20:28PM +0200, Jörg F. Wittenberger wrote:
On Sep 29 2011, Alan Post wrote:
Hence my question how to clean up the API. Default to possibly useless
re-calling the handler (while it assumes possibly having missed a signal
and hence re-check everything)? Provide a
On Sep 29 2011, Alan Post wrote:
On Thu, Sep 29, 2011 at 10:20:28PM +0200, Jörg F. Wittenberger wrote:
On Sep 29 2011, Alan Post wrote:
Hence my question how to clean up the API. Default to possibly
useless re-calling the handler (while it assumes possibly having
missed a signal and hence
24 matches
Mail list logo
