Hi,
in this message
http://lists.nongnu.org/archive/html/chicken-users/2011-09/msg00292.html
I sent out a strange bug. Sorry for that.
The child-registering fork() should be:
(define (save-fork)
(let* ((ie (##sys#fudge 14))
(pid (begin (chicken-disable-interrupts!)
Now let's see how we can use those modifications.
This code is far from what I'd like it to be.
It starts out with the idea, that it tries to resemble the
process-wait API as it stands.
However in the presence of green threads I feel that the API
is not the best we could have. This translates
On Sep 30 2011, Jörg F. Wittenberger wrote:
;; Now a tentatively replacement for process-wait. I'm not using
;; That anywhere. Falls back to the state of affairs in pid=0
(define (alt-process-wait pid nohang)
(if (= pid 0)
(process-wait pid nohang
(if nohang
Alan,
I figured that you did almost have you for the process-io-ports code
I cited the other day.
It might make your live easier, if I just post the code as I'm using
it right now.
Be warned: it does one thing NOT. When there is a bad fd encountered
while reading/writing to a fd, the
On Sep 30 2011, Jörg F. Wittenberger wrote:
Alan,
I figured that you did almost have you for the process-io-ports code
I cited the other day.
Alan, another warning: I just fixed a case of EINTR, where the code
shows strong heritage from the tcp unit. (I wrote some parallel code
base on it,
On Sep 30 2011, Alan Post wrote:
Thank you for this.
I notice, right away, that your io_needs_restart handles EAGAIN in
the same way it handles EINTR. I have always introduced a timeout
when I get an EAGAIN, and I give up after say 3 tries.
While I can follow the reasoning, it might not (or
There is one thing about the modified signaling:
I now can better see from the signal handler what all the thread
states are.
The bad (good actually, wild guesses before) news: it *is* possible
to end up with the current thread state as blocked.
However I just found out, and the thread which is
Alan Post scripsit:
It used to be one tested for sigaction in the same way you might
test for other features. I'm not sure if chicken runs on a
platform that doesn't have sigaction--do I need to add a feature
test for this and preserve the existing capability on platforms
without sigaction?
On Thu, Sep 29, 2011 at 10:44:42AM -0400, John Cowan wrote:
Alan Post scripsit:
It used to be one tested for sigaction in the same way you might
test for other features. I'm not sure if chicken runs on a
platform that doesn't have sigaction--do I need to add a feature
test for this and
On Sep 29 2011, John Cowan wrote:
Alan Post scripsit:
It used to be one tested for sigaction in the same way you might
test for other features. I'm not sure if chicken runs on a
platform that doesn't have sigaction--do I need to add a feature
test for this and preserve the existing
Here an interesting finding:
On Sep 29 2011, Alan Post wrote:
This patch replaces signal with sigaction for registering signals.
sigaction is a newer API for signal processing that fixes some
deficiencies of the original signal API. One fix can be seen in
this patch: we don't have to
On Thu, Sep 29, 2011 at 05:45:46PM +0200, Jörg F. Wittenberger wrote:
Here an interesting finding:
On Sep 29 2011, Alan Post wrote:
This patch replaces signal with sigaction for registering signals.
sigaction is a newer API for signal processing that fixes some
deficiencies of the
On Thu, Sep 29, 2011 at 02:15:29PM -0400, John Cowan wrote:
Alan Post scripsit:
Does the ANSI C behavior specify that a signal must be re-registered
after it is called? Is it more reliable for me to follow the ANSI
C standard or the w32 documentation on this interface? If w32,
where
Alan Post scripsit:
That's good enough (well not really *good*, but *enough*) to know
how to implement signal handling on missing-sigaction platforms.
You're right. Note also, however:
For floating-point exceptions, the value of func is not reset upon receiving
the signal.
--
John Cowan
On Thu, Sep 29, 2011 at 07:25:31AM -0600, Alan Post wrote:
This patch replaces signal with sigaction for registering signals.
sigaction is a newer API for signal processing that fixes some
deficiencies of the original signal API. One fix can be seen in
this patch: we don't have to reregister
15 matches
Mail list logo
