Hi Alan!
* Alan Post alanp...@sunflowerriver.org [110929 05:51]:
Looking at posixunix.scm, I find that some error messages are
produced with ##sys#error, and others with posix-error. What
distinguishes these two routines? Why would I use one but not
the other?
(define posix-error
(let
On Sep 29 2011, Alan Post wrote:
Below is a test case for a problem I'm seeing in some multi-process
code I'm writing. I'm getting the error:
Error: (file-read) cannot read from file - Interrupted system call
There are two ways to fix that: either make the posix unit thread safe
(recall my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 08:36 AM, Christian Kellermann wrote:
Hi Alan!
* Alan Post alanp...@sunflowerriver.org [110929 05:51]:
Looking at posixunix.scm, I find that some error messages are
produced with ##sys#error, and others with posix-error. What
* Alaric Snell-Pym ala...@snell-pym.org.uk [110929 13:18]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 08:36 AM, Christian Kellermann wrote:
Hi Alan!
* Alan Post alanp...@sunflowerriver.org [110929 05:51]:
Looking at posixunix.scm, I find that some error messages are
On Sep 29 2011, Alan Post wrote:
On Thu, Sep 29, 2011 at 12:09:19PM +0900, Alex Shinn wrote:
On Thu, Sep 29, 2011 at 11:40 AM, Alan Post
alanp...@sunflowerriver.org wrote:
Will you show me this data for the current implementation?
The first implementation doesn't need to justify itself,
On Sep 29 2011, Alaric Snell-Pym wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 08:36 AM, Christian Kellermann wrote:
Hi Alan!
* Alan Post alanp...@sunflowerriver.org [110929 05:51]:
Looking at posixunix.scm, I find that some error messages are
produced with ##sys#error,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote:
I don't not have benchmarks for a reason: they would cost me too much
time to do right. Personally I don't believe too much in benchmarks
anyway. I believe in fast execution and source code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 12:41 PM, Jörg F. Wittenberger wrote:
The core units are compiled without interrupt checking.
There is no chicken thread switch coming in here.
Oh, good. Stand down all units :-)
ABS
- --
Alaric Snell-Pym
On Wed, Sep 28, 2011 at 05:29:46PM -0601, Alan Post wrote:
Below is a test case for a problem I'm seeing in some multi-process
code I'm writing. I'm getting the error:
Error: (file-read) cannot read from file - Interrupted system call
because a signal handler is going off while my main
On Thu, Sep 29, 2011 at 01:11:49PM +0200, Jörg F. Wittenberger wrote:
On Sep 29 2011, Alan Post wrote:
Below is a test case for a problem I'm seeing in some multi-process
code I'm writing. I'm getting the error:
Error: (file-read) cannot read from file - Interrupted system call
There
On Sep 29 2011, Alaric Snell-Pym wrote:
On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote:
I don't not have benchmarks for a reason: they would cost me too much
time to do right. Personally I don't believe too much in benchmarks
anyway. I believe in fast execution and source code review.
Hi Jörg,
On 29 Sep 2011 13:11:49 +0200 Jörg F. Wittenberger
joerg.wittenber...@softeyes.net wrote:
Recently (maybe 4.7.3 or .4) I'm seeing missbehavior from formerly
well working code. I can't say that's chickens fault but neither I
can say it's not.
4.7.3 has a bug that may affect your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 01:44 PM, Jörg F. Wittenberger wrote:
On Sep 29 2011, Alaric Snell-Pym wrote:
On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote:
I don't not have benchmarks for a reason: they would cost me too much
time to do right. Personally I
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
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
On Sep 29 2011, Alan Post wrote:
On Thu, Sep 29, 2011 at 01:11:49PM +0200, Jörg F. Wittenberger wrote:
On Sep 29 2011, Alan Post wrote:
Below is a test case for a problem I'm seeing in some multi-process
code I'm writing. I'm getting the error:
Error: (file-read) cannot read from file -
On Thu, Sep 29, 2011 at 03:26:22PM +0200, Jörg F. Wittenberger wrote:
Attempt work around: defer the signal even more: until next schedule
time. I'm not yet satisfied with that solution. (But at least it
allows me to run arbitrary code in the signal handler.)
(I intended so far to try
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.
On Thu, Sep 29, 2011 at 03:26:22PM +0200, Jörg F. Wittenberger wrote:
Signal handlers as they are in chicken might be problematic.
I can't find the message, but I recall a reply these days, which
informed me that it's true that chicken interrupt handlers are
in fact in a restricted dialect of
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
-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
Alaric Snell-Pym scripsit:
Ooof, is that correct? IIRC, strerror isn't thread safe. We may not be
using POSIX threads, but might Chicken not schedule a new thread between
strerror and string-append, which might itself call strerror and thus
produce an invalid error message? I'm not sure at
On Sep 29 2011, Alan Post wrote:
On Thu, Sep 29, 2011 at 03:26:22PM +0200, Jörg F. Wittenberger wrote:
Signal handlers as they are in chicken might be problematic.
I can't find the message, but I recall a reply these days, which
informed me that it's true that chicken interrupt handlers are
in
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
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
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 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
Alaric Snell-Pym scripsit:
If the supposed performance improvement can't be benchmarked, then
it's pointless, as nobody will actually benefit from it. Any case
where somebody can benefit from a performance improvement can be
turned into a benchmark that consists of running the code that is
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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 04:51 PM, John Cowan wrote:
Alaric Snell-Pym scripsit:
If the supposed performance improvement can't be benchmarked, then
it's pointless, as nobody will actually benefit from it. Any case
where somebody can benefit from a
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 Sep 29 2011, Alan Post wrote:
Let me try a demonstration showing just the main thread:
(define (restart-read fd buf isize)
; call read(2), on the self-pipe, which blocks
(let ((r (file-read fd buf isize)))
(if (= -1 r)
; ah, a signal was delivered. In Chicken, the signal
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 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 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:
On Sep 29 2011, Alan Post wrote:
Let me try a demonstration showing just the main thread:
(define (restart-read fd buf isize)
; call read(2), on the self-pipe, which blocks
(let ((r (file-read fd buf isize)))
(if (= -1 r)
; ah, a
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
I'm still asking myself why I can't run chicken program under valgrind.
Since there's a lot going on at this time I'm about to forget.
Hence here an update for those who care and the archive.
I've traced the call coming from irregex.c down to valgrind complaining
as soon as *all-chars* value is
On Thu, Sep 29, 2011 at 09:38:44PM +0200, Jörg F. Wittenberger wrote:
I'm still asking myself why I can't run chicken program under valgrind.
Since there's a lot going on at this time I'm about to forget.
Hence here an update for those who care and the archive.
I've traced the call coming
On Sep 29 2011, Alan Post wrote:
Since it seems as good a day as any for wild-ass speculation, what
about this scenario:
We allocate an object, set the tag pointer, but don't fill out all
of the memory yet. We're yet to need it.
Oops! The gc gets called, and that object has to move. So we
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
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
53 matches
Mail list logo
