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!)
((
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 i
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
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,
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.
My use case here:
Let's say fork() returns EAGAIN. This could happen because ulimit
ha
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 read/writ
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
(process-te
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 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 reregist
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 Cowa
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,
>
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 do I find that?
The Woe32 documentation is silent about such fi
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 th
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 reregiste
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 capability
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
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 sigact
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 the signal handler after
a signal is sent.
That prevents a race
18 matches
Mail list logo