Re: [Chicken-hackers] pending patches
On Mon, Mar 12, 2012 at 12:50:56PM +0100, Felix wrote: - [PATCH] fix special cases for vector/list-ref in scrutinizer when argument count is wrong (here there's a reply with a modified patch) Hm. Can't find that one. original mail: http://lists.nongnu.org/archive/html/chicken-hackers/2012-02/msg00050.html I replied to that twice, but nongnu has issues displaying the thread properly. So here's the link of my second reply directly: http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00018.html Signed off and pushed. - [CR] deprecate make syntax in setup-api (you said you'd send a patch to the list for this one) Did so just now. Thank you. I'll take a look later unless someone beats me to it. The patch is attached to the ticket. Can someone please take care of this? - Re: [Chicken-hackers] [PATCH] random returns the same number on x86_64 all the time (this is a reply to a patch mail which was applied, but the reply contains another patch) I lost track. All patches were applied except for the final one: http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00019.html Signed off and pushed. - [PATCH] Bugfix for #791 and unpack flonums correctly for integer? Can't remember. http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00010.html Signed off and pushed. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
From: Christian Kellermann ck...@pestilenz.org Subject: Re: [Chicken-hackers] pending patches Date: Mon, 12 Mar 2012 16:04:29 +0100 * felix winkelmann fe...@call-with-current-continuation.org [120312 12:53]: - [PATCH] Raise error on construction of too large vectors/blobs (this is a long thread with multiple patches) I have to review this, since it seems to duplicate ##sys#check-range. Oh, that has been your concern? I have completely misinterpreted your mail then... It can still work fine without introducing the replication. I can rework this if needed. The error message would be a bit less clear then but the core leaner, which I like (better error messages are second in the like list)... If you could change the patch to use ##sys#check-range, I'd be grateful. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
* felix winkelmann fe...@call-with-current-continuation.org [120316 08:33]: - [PATCH] Bugfix for #791 and unpack flonums correctly for integer? Can't remember. http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00010.html Signed off and pushed. This patch breaks the tests for me. This is due to library tests being compiled with specialisation. The test in question is: (assert (not (integer? +inf.))) This works fine in csi: #;1 (not (integer? +inf.)) #t Also the assert works fine. Did make check pass for you with the compiled library tests? I am testing on a 64 bit linux. Cheers, Christian -- 9 out of 10 voices in my head say, that I am crazy, one is humming. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
* felix winkelmann fe...@call-with-current-continuation.org [120316 08:34]:
From: Christian Kellermann ck...@pestilenz.org
Subject: Re: [Chicken-hackers] pending patches
Date: Mon, 12 Mar 2012 16:04:29 +0100
* felix winkelmann fe...@call-with-current-continuation.org [120312
12:53]:
- [PATCH] Raise error on construction of too large vectors/blobs
(this is a long thread with multiple patches)
I have to review this, since it seems to duplicate ##sys#check-range.
Oh, that has been your concern? I have completely misinterpreted
your mail then... It can still work fine without introducing the
replication. I can rework this if needed. The error message would
be a bit less clear then but the core leaner, which I like (better
error messages are second in the like list)...
If you could change the patch to use ##sys#check-range, I'd be
grateful.
I have changed the patch to do that. I have also removed the check
for negative values in make-vector as check-range will do that for
us too.
The procedures in srfi-4 use its own version of check-range as this
will be inlined. (This has already existed, and I am reusing this).
The latest version is attached here.
Thanks!
Christian
--
9 out of 10 voices in my head say, that I am crazy,
one is humming.
From 0eb7ffc6c4e95538e1d916e14955b7480e2cbdbd Mon Sep 17 00:00:00 2001
From: Christian Kellermann ck...@pestilenz.org
Date: Sun, 4 Mar 2012 10:16:01 +0100
Subject: [PATCH] Raise error on construction of too large vectors/blobs
too large depends on the C_HEADER_SIZE_MASK bits for library blobs
and vectors and decreases with the kind of vector for srfi-4 units.
This patch also adds the respective test cases for library and srfi-4
tests.
The manual section on the srfi-4 unit has been amended to explain the
size limits.
---
library.scm |6 +++---
manual/Unit srfi-4 | 18 ++
srfi-4.scm | 32 ++--
tests/library-tests.scm | 30 ++
tests/srfi-4-tests.scm | 39 ++-
5 files changed, 107 insertions(+), 18 deletions(-)
diff --git a/library.scm b/library.scm
index cc84da1..2381a8f 100644
--- a/library.scm
+++ b/library.scm
@@ -151,6 +151,7 @@ EOF
(define-constant read-line-buffer-initial-size 1024)
(define-constant default-parameter-vector-size 16)
(define maximal-string-length (foreign-value C_HEADER_SIZE_MASK
unsigned-long))
+(define maximal-vector-size (foreign-value C_HEADER_SIZE_MASK unsigned-long))
;;; System routines:
@@ -1281,7 +1282,7 @@ EOF
bv) )
(define (make-blob size)
- (##sys#check-exact size 'make-blob)
+ (##sys#check-range size 0 maximal-vector-size 'make-blob)
(##sys#make-blob size) )
(define (blob? x)
@@ -1322,8 +1323,7 @@ EOF
(define (vector-set! v i x) (##core#inline C_i_vector_set v i x))
(define (##sys#make-vector size . fill)
- (##sys#check-exact size 'make-vector)
- (when (fx size 0) (##sys#error 'make-vector size is negative size))
+ (##sys#check-range size 0 maximal-vector-size 'make-vector)
(##sys#allocate-vector
size #f
(if (null? fill)
diff --git a/manual/Unit srfi-4 b/manual/Unit srfi-4
index cbd167f..ff573b8 100644
--- a/manual/Unit srfi-4
+++ b/manual/Unit srfi-4
@@ -13,6 +13,24 @@ Homogeneous numeric vector datatypes. Also see the
[[http://srfi.schemers.org/s
* Constructors allow allocating the storage in non garbage collected memory.
* 64-bit integer vectors ({{u64vector}} and {{s64vector}}) are not supported.
+=== Size limitations
+
+SRFI-4 vectors internally are implemented with a maximum length of
+0xff (on 32bit platforms) or 0xff (on 64bit platforms)
+'''bytes'''. This limits the number of possible vector elements:
+
+* All byte vectors have a maximum number of entries of 0xff (32
+ bit) / 0xff (64 bit)
+
+* All 16 bit vectors have a maximum number of entries of 0x7f (32
+ bit) / 0x7f (64 bit)
+
+* All 32 bit vectors have a maximum number of entries of 0x3f (32
+ bit) / 0x3f (64 bit)
+
+* All 64 bit vectors have a maximum number of entries of 0x1f (32
+ bit) / 0x1f (64 bit)
+
=== Blob conversions
procedure(u8vector-blob U8VECTOR)/procedurebr
diff --git a/srfi-4.scm b/srfi-4.scm
index e82dc4e..41a748e 100644
--- a/srfi-4.scm
+++ b/srfi-4.scm
@@ -254,16 +254,16 @@ EOF
;;; Basic constructors:
-(let* ([ext-alloc
+(let* ((ext-alloc
(foreign-lambda* scheme-object ([int bytes])
C_word *buf = (C_word *)C_malloc(bytes + sizeof(C_header));
if(buf == NULL) C_return(C_SCHEME_FALSE);
C_block_header(buf) = C_make_header(C_BYTEVECTOR_TYPE, bytes);
- C_return(buf);) ]
- [ext-free
+ C_return(buf);) )
+ (ext-free
(foreign-lambda* void ([scheme-object bv])
- C_free((void *)C_block_item(bv, 1));) ]
- [alloc
+ C_free((void
Re: [Chicken-hackers] pending patches
On Mon, Mar 12, 2012 at 08:25:45AM +0100, Felix wrote: Hi! Too many patches are floating in limbo in the moment (and I'm aware of being unable to catch up, particularly in the case of the more involved patches which I really like to review before they go into master). There are no really involved ones left anymore, I think. A suggestion: if a patch remains pending for a longer period, it might be sensible to create a trac ticket, add the patch and assign the ticket to someone (when in doubt, assign it to me). Otherwise patches will get lost, or submitters will feel ignored. What works great for me is using the flag feature of mutt. When a message comes in, it start out being unread. When I read it and see it's a patch, I flag it. Then when someone applies the patch, I unflag it. So everything that requires attention is either unread or flagged. That way I can easily see which patches are still outstanding. These are, in chronological order: - [PATCH] fix special cases for vector/list-ref in scrutinizer when argument count is wrong (here there's a reply with a modified patch) - [CR] deprecate make syntax in setup-api (you said you'd send a patch to the list for this one) - Re: [Chicken-hackers] [PATCH] random returns the same number on x86_64 all the time (this is a reply to a patch mail which was applied, but the reply contains another patch) - [PATCH] Raise error on construction of too large vectors/blobs (this is a long thread with multiple patches) - [PATCH] Bugfix for #791 and unpack flonums correctly for integer? - [PATCH] Allow assert to accept an arbitrary expression as the message - [PATCH] Fix a few more mistakes in types.db Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-hackers] pending patches Date: Mon, 12 Mar 2012 10:13:29 +0100 On Mon, Mar 12, 2012 at 08:25:45AM +0100, Felix wrote: Hi! Too many patches are floating in limbo in the moment (and I'm aware of being unable to catch up, particularly in the case of the more involved patches which I really like to review before they go into master). There are no really involved ones left anymore, I think. A suggestion: if a patch remains pending for a longer period, it might be sensible to create a trac ticket, add the patch and assign the ticket to someone (when in doubt, assign it to me). Otherwise patches will get lost, or submitters will feel ignored. What works great for me is using the flag feature of mutt. When a message comes in, it start out being unread. When I read it and see it's a patch, I flag it. Then when someone applies the patch, I unflag it. So everything that requires attention is either unread or flagged. That way I can easily see which patches are still outstanding. These are, in chronological order: - [PATCH] fix special cases for vector/list-ref in scrutinizer when argument count is wrong (here there's a reply with a modified patch) Hm. Can't find that one. - [CR] deprecate make syntax in setup-api (you said you'd send a patch to the list for this one) Did so just now. - Re: [Chicken-hackers] [PATCH] random returns the same number on x86_64 all the time (this is a reply to a patch mail which was applied, but the reply contains another patch) I lost track. - [PATCH] Raise error on construction of too large vectors/blobs (this is a long thread with multiple patches) I have to review this, since it seems to duplicate ##sys#check-range. - [PATCH] Bugfix for #791 and unpack flonums correctly for integer? Can't remember. - [PATCH] Allow assert to accept an arbitrary expression as the message Ah, yeah. - [PATCH] Fix a few more mistakes in types.db Can't remember. What a mess. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
Hm. Can't find that one. original mail: http://lists.nongnu.org/archive/html/chicken-hackers/2012-02/msg00050.html I replied to that twice, but nongnu has issues displaying the thread properly. So here's the link of my second reply directly: http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00018.html All patches were applied except for the final one: http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00019.html Ok. I hope this mail helps to untangle it somewhat. It does. Thanks, Peter. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
* felix winkelmann fe...@call-with-current-continuation.org [120312 12:53]: - [PATCH] Raise error on construction of too large vectors/blobs (this is a long thread with multiple patches) I have to review this, since it seems to duplicate ##sys#check-range. Oh, that has been your concern? I have completely misinterpreted your mail then... It can still work fine without introducing the replication. I can rework this if needed. The error message would be a bit less clear then but the core leaner, which I like (better error messages are second in the like list)... Thanks Kind regards, Christian -- Who can (make) the muddy water (clear)? Let it be still, and it will gradually become clear. Who can secure the condition of rest? Let movement go on, and the condition of rest will gradually arise. -- Lao Tse. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
I have tried to devote some attention to this one and found that I am still no good at modifying Chicken and then successfully running the result. I do have some comments on the patch, which I had hoped to provide as a patch, but since I seem unable to do that, I will provide them more informally and please beg your forgiveness. Thanks for your comments, Alan. I appreciate your feedback and will try to give more information about the changes. diff --git a/library.scm b/library.scm index 8075c2f..9b65ad2 100644 --- a/library.scm +++ b/library.scm @@ -1736,9 +1746,17 @@ EOF (define ##sys#stream-port-class (vector (lambda (p) ; read-char - (##core#inline C_read_char p) ) + (let loop () + (let ((c (##core#inline C_read_char p))) + (if (eq? -1 c) ; EINTR + (##sys#dispatch-interrupt loop) + c (lambda (p) ; peek-char - (##core#inline C_peek_char p) ) + (let loop () + (let ((c (##core#inline C_peek_char p))) + (if (eq? -1 c) ; EINTR + (##sys#dispatch-interrupt loop) + c (lambda (p c) ; write-char (##core#inline C_display_char p c) ) (lambda (p s) ; write-string There are a whole class of functions that might return EINTR, and this set, read/peek, seem arbitrarily chosen to me. fcntl, nanosleep, wait, close amongst others can return EINTR. In my program that does signal handling, I catch this exception in the Scheme code and restart the exception. This is working for me, so I don't strictly need the library to do it. if it's going to, however, it seems like it should do it everywhere it can happen. (Other places in the code also do this, please consider this my representative comment for al of those places.) You are of course right. The Right Thing would be to wrap all calls to POSIX functions into EINTR handling code (if they can be interrupted). I chose those functions initially that have a potential to hang for a certain time, which means read/input functions. I think it is ok to start with these to not disrupt too much code at the same time. diff --git a/library.scm b/library.scm index 8075c2f..9b65ad2 100644 --- a/library.scm +++ b/library.scm @@ -4344,10 +4373,23 @@ EOF (define ##sys#context-switch (##core#primitive C_context_switch)) +(define ##sys#signal-vector (make-vector 256 #f)) + (define (##sys#interrupt-hook reason state) It turns out that there is a variable, _NSIG, defined in signal.h. I am pretty certain this variable is stable across Solaris, Linux, and BSD. It also is a value much closer to 32 than it is to 256. (Side note: I can recall several occasions where some definitions were believed to be pretty certain consistent across platforms, when in fact they were not) While 256 is nice and arbitrarily high, the actual size of this vector is properly defined in _NSIG. I think this vector should use that value rather than this magic number. I agree that 256 is probably too high. Rather than storing a queue of pending signals, we are permitted to store a masked set of pending signals, mimicking the same structure as it appears in the kernel. When a signal arrives, we can use the signal number as an index and mark the signal as pending. Then we can iterate over the signal maskset and deliver those signals. It is possible that we'll get a signal delivered twice or more and only deliver it to our Scheme code once, but the kernel already behaves this way, and we will always deliver *a* signal. In my testing, I was seeing SIGCHLD delivered 32 times for 256 child processes. 30 or 31 signals instead of 32 is truly not a problem. You are right, of course, but on the other hand it might be preferable to deliver as many signals as possible (even if not all signals can). There is nothing at all wrong with this implementation as it appears in the patch, save for the theoretically potential case of receiving more signals than we have space in the pending queue. I don't think we could actually exceed 100, because of kernel will discard duplicates and there just aren't enough signals to make it happen. So I'm stating that we can get away with a weaker guarantee (a mask rather than a queue) and still be every bit as reliable as we are now. In between the return of the signal handler and the dispatching of signals, any number of signals may come through. I still think it might be better to catch as many as possible. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
On Mon, Nov 14, 2011 at 01:51:47PM +0100, Felix wrote: I have tried to devote some attention to this one and found that I am still no good at modifying Chicken and then successfully running the result. I do have some comments on the patch, which I had hoped to provide as a patch, but since I seem unable to do that, I will provide them more informally and please beg your forgiveness. Thanks for your comments, Alan. I appreciate your feedback and will try to give more information about the changes. diff --git a/library.scm b/library.scm index 8075c2f..9b65ad2 100644 --- a/library.scm +++ b/library.scm @@ -1736,9 +1746,17 @@ EOF (define ##sys#stream-port-class (vector (lambda (p) ; read-char - (##core#inline C_read_char p) ) + (let loop () + (let ((c (##core#inline C_read_char p))) + (if (eq? -1 c) ; EINTR + (##sys#dispatch-interrupt loop) + c (lambda (p) ; peek-char - (##core#inline C_peek_char p) ) + (let loop () + (let ((c (##core#inline C_peek_char p))) + (if (eq? -1 c) ; EINTR + (##sys#dispatch-interrupt loop) + c (lambda (p c) ; write-char (##core#inline C_display_char p c) ) (lambda (p s) ; write-string There are a whole class of functions that might return EINTR, and this set, read/peek, seem arbitrarily chosen to me. fcntl, nanosleep, wait, close amongst others can return EINTR. In my program that does signal handling, I catch this exception in the Scheme code and restart the exception. This is working for me, so I don't strictly need the library to do it. if it's going to, however, it seems like it should do it everywhere it can happen. (Other places in the code also do this, please consider this my representative comment for al of those places.) You are of course right. The Right Thing would be to wrap all calls to POSIX functions into EINTR handling code (if they can be interrupted). I chose those functions initially that have a potential to hang for a certain time, which means read/input functions. I think it is ok to start with these to not disrupt too much code at the same time. diff --git a/library.scm b/library.scm index 8075c2f..9b65ad2 100644 --- a/library.scm +++ b/library.scm @@ -4344,10 +4373,23 @@ EOF (define ##sys#context-switch (##core#primitive C_context_switch)) +(define ##sys#signal-vector (make-vector 256 #f)) + (define (##sys#interrupt-hook reason state) It turns out that there is a variable, _NSIG, defined in signal.h. I am pretty certain this variable is stable across Solaris, Linux, and BSD. It also is a value much closer to 32 than it is to 256. (Side note: I can recall several occasions where some definitions were believed to be pretty certain consistent across platforms, when in fact they were not) While 256 is nice and arbitrarily high, the actual size of this vector is properly defined in _NSIG. I think this vector should use that value rather than this magic number. I agree that 256 is probably too high. Rather than storing a queue of pending signals, we are permitted to store a masked set of pending signals, mimicking the same structure as it appears in the kernel. When a signal arrives, we can use the signal number as an index and mark the signal as pending. Then we can iterate over the signal maskset and deliver those signals. It is possible that we'll get a signal delivered twice or more and only deliver it to our Scheme code once, but the kernel already behaves this way, and we will always deliver *a* signal. In my testing, I was seeing SIGCHLD delivered 32 times for 256 child processes. 30 or 31 signals instead of 32 is truly not a problem. You are right, of course, but on the other hand it might be preferable to deliver as many signals as possible (even if not all signals can). There is nothing at all wrong with this implementation as it appears in the patch, save for the theoretically potential case of receiving more signals than we have space in the pending queue. I don't think we could actually exceed 100, because of kernel will discard duplicates and there just aren't enough signals to make it happen. So I'm stating that we can get away with a weaker guarantee (a mask rather than a queue) and still be every bit as reliable as we are now. In between the return of the signal handler and the dispatching of signals, any number of signals may come through. I still think it might be better to catch as many as possible. cheers, felix This is all fine, then. I don't have any additional feedback. -Alan -- .i ma'a lo bradi cu penmi gi'e
Re: [Chicken-hackers] pending patches
Hi! * felix winkelmann fe...@call-with-current-continuation.org [11 14:10]: Note that the following patches are still pending for review: http://lists.nongnu.org/archive/html/chicken-hackers/2011-11/msg9.html I must have overslept pushing that one after our little exchange, will push this one next. http://lists.nongnu.org/archive/html/chicken-hackers/2011-11/msg00010.html This I will need a little more time, if someone likes to take over (or work in parallel) she is more than welcome to. This is also a critical part that could need more eyes than mine. http://lists.nongnu.org/archive/html/chicken-hackers/2011-11/msg00016.html I have acked and pushed this one. http://lists.nongnu.org/archive/html/chicken-hackers/2011-11/msg00017.html This is currently under review, I will get back shortly. Kind regards, Christian -- Who can (make) the muddy water (clear)? Let it be still, and it will gradually become clear. Who can secure the condition of rest? Let movement go on, and the condition of rest will gradually arise. -- Lao Tse. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
On Fri, Nov 11, 2011 at 02:29:59PM +0100, Christian Kellermann wrote:
http://lists.nongnu.org/archive/html/chicken-hackers/2011-11/msg00010.html
This I will need a little more time, if someone likes to take over
(or work in parallel) she is more than welcome to. This is also a critical
part that could need more eyes than mine.
I have tried to devote some attention to this one and found that I
am still no good at modifying Chicken and then successfully running
the result. I do have some comments on the patch, which I had hoped
to provide as a patch, but since I seem unable to do that, I will
provide them more informally and please beg your forgiveness.
diff --git a/library.scm b/library.scm
index 8075c2f..9b65ad2 100644
--- a/library.scm
+++ b/library.scm
@@ -1736,9 +1746,17 @@ EOF
(define ##sys#stream-port-class
(vector (lambda (p) ; read-char
- (##core#inline C_read_char p) )
+ (let loop ()
+ (let ((c (##core#inline C_read_char p)))
+ (if (eq? -1 c) ; EINTR
+ (##sys#dispatch-interrupt loop)
+ c
(lambda (p) ; peek-char
- (##core#inline C_peek_char p) )
+ (let loop ()
+ (let ((c (##core#inline C_peek_char p)))
+ (if (eq? -1 c) ; EINTR
+ (##sys#dispatch-interrupt loop)
+ c
(lambda (p c) ; write-char
(##core#inline C_display_char p c) )
(lambda (p s) ; write-string
There are a whole class of functions that might return EINTR, and
this set, read/peek, seem arbitrarily chosen to me. fcntl,
nanosleep, wait, close amongst others can return EINTR. In my
program that does signal handling, I catch this exception in the
Scheme code and restart the exception. This is working for me,
so I don't strictly need the library to do it. if it's going
to, however, it seems like it should do it everywhere it can happen.
(Other places in the code also do this, please consider this my
representative comment for al of those places.)
diff --git a/library.scm b/library.scm
index 8075c2f..9b65ad2 100644
--- a/library.scm
+++ b/library.scm
@@ -4344,10 +4373,23 @@ EOF
(define ##sys#context-switch (##core#primitive C_context_switch))
+(define ##sys#signal-vector (make-vector 256 #f))
+
(define (##sys#interrupt-hook reason state)
It turns out that there is a variable, _NSIG, defined in signal.h.
I am pretty certain this variable is stable across Solaris, Linux,
and BSD. It also is a value much closer to 32 than it is to 256.
While 256 is nice and arbitrarily high, the actual size of this
vector is properly defined in _NSIG. I think this vector should
use that value rather than this magic number.
diff --git a/runtime.c b/runtime.c
index a6b2d35..3b00673 100644
--- a/runtime.c
+++ b/runtime.c
@@ -159,6 +160,8 @@ extern void _C_do_apply_hack(void *proc, C_word
*args, int
count) C_noret;
#define FILE_INFO_SIZE 7
+#define MAX_PENDING_INTERRUPTS 100
+
#ifdef C_DOUBLE_IS_32_BITS
# define FLONUM_PRINT_PRECISION 7
#else
@@ -441,6 +444,9 @@ static C_TLS FINALIZER_NODE
static C_TLS void *current_module_handle;
static C_TLS int flonum_print_precision = FLONUM_PRINT_PRECISION;
static C_TLS HDUMP_BUCKET **hdump_table;
+static C_TLS int
+ pending_interrupts[ MAX_PENDING_INTERRUPTS ],
+ pending_interrupts_count;
/* Prototypes: */
@@ -690,6 +696,7 @@ int CHICKEN_initialize(int heap, int stack, int
symbols,
void *toplevel)
C_clear_trace_buffer();
chicken_is_running = chicken_ran_once = 0;
interrupt_reason = 0;
+ pending_interrupts_count = 0;
last_interrupt_latency = 0;
C_interrupts_enabled = 1;
C_initial_timer_interrupt_period =
INITIAL_TIMER_INTERRUPT_PERIOD;
@@ -4197,16 +4217,25 @@ C_regparm void C_fcall
C_paranoid_check_for_interrupt(void)
C_regparm void C_fcall C_raise_interrupt(int reason)
{
if(C_interrupts_enabled) {
-saved_stack_limit = C_stack_limit;
+if(interrupt_reason) {
+ if(reason != C_TIMER_INTERRUPT_NUMBER) {
+ if(pending_interrupts_count MAX_PENDING_INTERRUPTS)
+ /* drop signals if too many */
+ pending_interrupts[ pending_interrupts_count++ ] = reason;
+ }
+}
+else {
+ saved_stack_limit = C_stack_limit;
#if C_STACK_GROWS_DOWNWARD
C_stack_limit = C_stack_pointer + 1000;
@@ -9168,3 +9209,19 @@ C_i_file_exists_p(C_word name, C_word file,
C_word dir)
}
+C_regparm C_word C_fcall
+C_i_pending_interrupt(C_word dummy)
+{
+ int i;
+
+ if(interrupt_reason interrupt_reason !=
C_TIMER_INTERRUPT_NUMBER) {
+i = interrupt_reason;
+interrupt_reason = 0;
+return C_fix(i);
+ }
+
+ if(pending_interrupts_count 0)
+return C_fix(pending_interrupts[ --pending_interrupts_count ]);
+
+ return C_SCHEME_FALSE;
+}
I've been running this patch, and this code is working
