Re: [Chicken-users] remove enable/disable interrupt flag

[alaric]

>> AIUI mmap of /dev/zero (to allocate more
>> empty heap) can't block on very much...

>I don't think you can mmap a 
> device, can you?

Sure you can! Mmapping /dev/zero gets you zeroed writable pages and, last I 
looked, is how the heap is obtained. Devices representing frame buffers support 
mapping, too, and map a memory-mapped I/O region into the userland address 
space. Maybe /dev/kmem and friends work for mapping kernel memory, too... Not 
so sure about that. Obviously the likes of ttys don't ;-)

--Original Message--
From: John Cowan
Sender: John Cowan
To: Alaric Snell-Pym
Cc: 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 to give us legroom for
> any fun and games that may occur in the runtime.

The chance of a stack blowup is essentially nil.  Chicken, the last time
I looked, has a stack limit of 64K; typical desktop OSes provide stack
sizes in the megabytes by default.

Of course, if you wind up the C stack by having Chicken call C which calls
Chicken which calls C to some serious depth, all bets are off.

> 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
you use sigaction() to catch them.  I suspect that most of our systems
in fact will work with signal(), as it's just a thin layer over sigaction(),
but better not to rely on that.

> AIUI mmap of /dev/zero (to allocate more
> empty heap) can't block on very much...

I don't think you can mmap a device, can you?

-- 
I don't know half of you half as well   John Cowan
as I should like, and I like less than half co...@ccil.org
of you half as well as you deserve. http://www.ccil.org/~cowan
--Bilbo



Sent from my BlackBerry® wireless device
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[John Cowan]

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 interface, sigqueue(), which does have guaranteed delivery.

-- 
MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
John Cowan  co...@ccil.org  http://www.ccil.org/~cowan

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Jörg F . Wittenberger]

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
not-withstanding.


By all means:  given the frequency and variations I'm testing
theses days.

Furthermore: even a wrapper could created minor differences in
the actual execution sequence.  Read: timing.
To have or not to have it might be critical for the bug you are
after to escape for some more time.

Folklore along the way: once we ran into a gcc bug.  It did show
up rarely (but eventually too often) in RScheme's block allocation.
(Turned out to be only at the then new AMD 64 due to bad instruction
scheduling of gcc.  The C code was valid.)




___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

> > 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
> you use sigaction() to catch them.  I suspect that most of our systems
> in fact will work with signal(), as it's just a thin layer over sigaction(),
> but better not to rely on that.
> 

I wrote a test program (below) to test signal delivery from C.  I
was surprised to find signals being coalesced on OpenBSD, my test
system.  This program for me receives far fewer than 256 signals.

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
not-withstanding.

-Alan

<++> gcc -o child child.c && ./child
#include 
#include 
#include 
#include 
#include 
#include 
#include 

volatile sig_atomic_t child_count=0;

void
chld(int signum)
{
  ++child_count;
}

main()
{
  struct sigaction sa;
  int i, status;
pid_t pid;

sa.sa_handler=chld;
sa.sa_flags = 0;
sigemptyset(&sa.sa_mask);
sigaddset(&sa.sa_mask, SIGCHLD);

sigaction(SIGCHLD, &sa, 0);

  for(i=0; i<256; ++i) {
  switch(pid=fork()) {
case -1:
fprintf(stderr, "fork: %s\n", strerror(errno));
continue;
  case 0:
  _exit(0);
  default:
  break;
}
}

for(i=0; i<256; ++i) {
restart_wait:
if(-1==waitpid(WAIT_ANY, &status, 0)) {
if(EINTR==errno) goto restart_wait;
fprintf(stderr, "wait: %s\n", strerror(errno));
break;
}
}

printf("%d\n", child_count);
exit(0);
}
<-->
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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, I only look into signal handling occasionally!
> 

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.
A test program on *BSD confirms that this operating system does not,
and Linux likely follows.  So we don't need that queue--I think I
managed to see Chicken drop one signal testing last night, but I've
not confirmed this yet and it wouldn't be a crisis should it
actually do so.  I haven't tried a more complex case I think Chicken
does suffer from, which is near-arrival of two separate signals.

At any rate, my suggestion of a signal queue was based on an
incorrect understanding of the signal mechanism and I withdraw it.


> > And that we also *must* handle
> > deferred signals before making another syscall, whether that syscall
> > happened from user code or whether we're making a syscall in service
> > to the need of the runtime.
> 
> The one tricky case I can think of is when the chicken signal handler
> needs more RAM (so the GC is invoked) and the GC needs to malloc things
> in the heap and the heap needs to grow, so a mmap (which is what sbrk
> seems to be called these days) occurs... Do you need it run before ALL
> syscalls, or just ones that might block on something the signal handler
> might be needed to relieve? AIUI mmap of /dev/zero (to allocate more
> empty heap) can't block on very much...
> 

I'm currently hoping that it can be run just before the ones that
block, which is an astute observation, thank you.  I'll probably
need to sit down with the signals one-by-one to be sure, but I
think this "weaker" constraint is fully correct.


> > I think is a fantastic outline of what needs to happen.  I will work on
> > a patch, with no guarantee of how fast I will be.
> 
> Tell me if I can help - I want to gain a deeper understanding of the
> Chicken scheduler!
> 

Thank you!

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[John Cowan]

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 to give us legroom for
> any fun and games that may occur in the runtime.

The chance of a stack blowup is essentially nil.  Chicken, the last time
I looked, has a stack limit of 64K; typical desktop OSes provide stack
sizes in the megabytes by default.

Of course, if you wind up the C stack by having Chicken call C which calls
Chicken which calls C to some serious depth, all bets are off.

> 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
you use sigaction() to catch them.  I suspect that most of our systems
in fact will work with signal(), as it's just a thin layer over sigaction(),
but better not to rely on that.

> AIUI mmap of /dev/zero (to allocate more
> empty heap) can't block on very much...

I don't think you can mmap a device, can you?

-- 
I don't know half of you half as well   John Cowan
as I should like, and I like less than half co...@ccil.org
of you half as well as you deserve. http://www.ccil.org/~cowan
--Bilbo

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alaric Snell-Pym]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2011 05:24 PM, Alan Post wrote:

[signal near stack limit]
> The Minix source code is illustrative on this point.  I think a
> program being near the stack limit when a signal arrives is the only
> time in that operating system that a process will be killed without
> the normal mechanims the kernel goes through--It just tosses the
> thing out.
>
> I've never looked at how this behaves on *BSD or Linux, but I
> imagine there is a similar condition (or as you outline above,
> a reserve available).  So this comes up even in C, which at least
> on Minux is not a handleable condition.

Yeah. We need to make sure that Chicken's stack limit (which triggers a
GC) is sufficiently clear of the real stack limit to give us legroom for
any fun and games that may occur in the runtime.

> I pretty much rely on my registered signal handler being in the
> dynamic environment it was declared in.  The EINTR test case uses
> this to get hold of a file descriptor created in the main thread.

It does seem the most sensible approach.

> I'll add that we might of course get a signal while performing GC,
> a case that needs to be accounted for.

Yep. The C signal handler will queue the chicken signal for happening in
due course.

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, I only look into signal handling occasionally!

> And that we also *must* handle
> deferred signals before making another syscall, whether that syscall
> happened from user code or whether we're making a syscall in service
> to the need of the runtime.

The one tricky case I can think of is when the chicken signal handler
needs more RAM (so the GC is invoked) and the GC needs to malloc things
in the heap and the heap needs to grow, so a mmap (which is what sbrk
seems to be called these days) occurs... Do you need it run before ALL
syscalls, or just ones that might block on something the signal handler
might be needed to relieve? AIUI mmap of /dev/zero (to allocate more
empty heap) can't block on very much...

> I think is a fantastic outline of what needs to happen.  I will work on
> a patch, with no guarantee of how fast I will be.

Tell me if I can help - I want to gain a deeper understanding of the
Chicken scheduler!

> -Alan

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6FfhUACgkQRgz/WHNxCGrIGwCfSQzbYydzuIVB2QFNeX2w0SJA
vkAAnRou8EO7rA7XZunVZ9VQlU0h0MSw
=dh/W
-END PGP SIGNATURE-

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Jörg F . Wittenberger]

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 re-check everything)? Provide a modified 
>> API which covers both cases? ...

>>
>
>It may have been posted before I was really attending to this
>conversation.  I can't find it in my archive.  Would you mind
>sending it to me again?

Not at all.

Given the doubt whether or not this conversation pertains to the before
mentioned issue https://bugs.call-cc.org/ticket/668 I'm not sure:
should we take this conversation private for a while or not.

The situation is: right now I'm running from a modified chicken. 
Changes have been made to a) the signal handling b) the finalizer_list 
and list constructors as posted recently c) the scheduler and srfi-18 
(ages ago) d) for historic reasons: the time representation (see below 
for an excuse)


At least for (d) there is no reason for you to swallow that one.

(c) might fix a bug - risky enough if your code relies on it -- or it
may introduce one my code relies on.

The note to take to the chicken community: it's a nice feature in a way,
that chicken needs only on .h and on .c file plus your code.  But this
features now shows it's downside: it's hard to merge independent changes.
It's hard to track the common ground.

However (c) does have some overlap with (a) - which would be what you 
are interested in to begin with. We will not be able to reconcile 
without manual intervention.


Worse: (a) and (d) do overlap in runtime.c and chicken.c (for what the
excuse is worth)...

Alan, what would be the best?  Several postings on the list detailing
the changes (good for documentation; needs manual integration always;
thereby forcing code review)?  A full diff from current git to my
current state of affairs (watch out for excuses below!)?

/Jörg



Fun!  I'd rather look at an isolated a), even if it doesn't compile,
than try to digest the rest of this too.

If you can just send me the parts of your tree that pertain to a),
even if that patch does not result in code that compiles, that would
help me the most.

It's ok if, for instance, I get a patch that leads off into b, c, or
d and you just fail to include that.

Will you do this?  I am curious to see your signal handling patch.

-Alan



I'll do so.  But I have to call this a day for today.

Some sad news: it looks as if things are much better now on Linux/AMD64
but the Sheeva Plug seems to still loose on i/o.  I even got the feeling
that it might loose more than before.  (Which could be a hint for the
days to come.)







___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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 modified API which covers
> >>both cases? ...
> >>
> >
> >It may have been posted before I was really attending to this
> >conversation.  I can't find it in my archive.  Would you mind
> >sending it to me again?
> 
> Not at all.
> 
> Given the doubt whether or not this conversation pertains to the before
> mentioned issue https://bugs.call-cc.org/ticket/668 I'm not sure:
> should we take this conversation private for a while or not.
> 
> The situation is: right now I'm running from a modified chicken.
> Changes have been made to
> a) the signal handling
> b) the finalizer_list and list constructors as posted recently
> c) the scheduler and srfi-18 (ages ago)
> d) for historic reasons: the time representation (see below for an excuse)
> 
> At least for (d) there is no reason for you to swallow that one.
> 
> (c) might fix a bug - risky enough if your code relies on it -- or it
> may introduce one my code relies on.
> 
> The note to take to the chicken community: it's a nice feature in a way,
> that chicken needs only on .h and on .c file plus your code.  But this
> features now shows it's downside: it's hard to merge independent changes.
> It's hard to track the common ground.
> 
> However (c) does have some overlap with (a) - which would be what you
> are interested in to begin with.  We will not be able to reconcile without
> manual intervention.
> 
> Worse: (a) and (d) do overlap in runtime.c and chicken.c (for what the
> excuse is worth)...
> 
> Alan, what would be the best?  Several postings on the list detailing
> the changes (good for documentation; needs manual integration always;
> thereby forcing code review)?  A full diff from current git to my
> current state of affairs (watch out for excuses below!)?
> 
> /Jörg
> 

Fun!  I'd rather look at an isolated a), even if it doesn't compile,
than try to digest the rest of this too.

If you can just send me the parts of your tree that pertain to a),
even if that patch does not result in code that compiles, that would
help me the most.

It's ok if, for instance, I get a patch that leads off into b, c, or
d and you just fail to include that.

Will you do this?  I am curious to see your signal handling patch.

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Jörg F . Wittenberger]

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 I was really attending to this
conversation.  I can't find it in my archive.  Would you mind
sending it to me again?


Not at all.

Given the doubt whether or not this conversation pertains to the before
mentioned issue https://bugs.call-cc.org/ticket/668 I'm not sure:
should we take this conversation private for a while or not.

The situation is: right now I'm running from a modified chicken.
Changes have been made to
a) the signal handling
b) the finalizer_list and list constructors as posted recently
c) the scheduler and srfi-18 (ages ago)
d) for historic reasons: the time representation (see below for an excuse)

At least for (d) there is no reason for you to swallow that one.

(c) might fix a bug - risky enough if your code relies on it -- or it
may introduce one my code relies on.

The note to take to the chicken community: it's a nice feature in a way,
that chicken needs only on .h and on .c file plus your code.  But this
features now shows it's downside: it's hard to merge independent changes.
It's hard to track the common ground.

However (c) does have some overlap with (a) - which would be what you
are interested in to begin with.  We will not be able to reconcile without
manual intervention.

Worse: (a) and (d) do overlap in runtime.c and chicken.c (for what the
excuse is worth)...

Alan, what would be the best?  Several postings on the list detailing
the changes (good for documentation; needs manual integration always;
thereby forcing code review)?  A full diff from current git to my
current state of affairs (watch out for excuses below!)?

/Jörg

PS: The Excuse

Since I've only recently reached the state of affairs that I can expose
the Chicken-compiled version of Askemos to the net without keeping an
eye on the firewall, I did so far not even dare to change the time
representation for a reason unrelated to Chicken.  So far the only
Scheme for which there was a working implementation of Askemos/BALL
was RScheme.  Therefore the network ran all public nodes on RScheme.
Now the DHT is updated in byzantine agreement, whereby a "current time"
(which is not the current-time from Chicken) is going to be part of
the checksum the agreement in being run on.  One of the closest-to-worst
cases which could hit me would be, if due to some hypothetical rounding
error representing the same time value for the checksum would occasionally
result in a different representation under RScheme and Chicken.
(Which in turn would make the update fail.  If all that byzantine agreement
relates stuff does not make any sense to you:  take the idea of
http://code.google.com/p/upright/ - you find an API where you plug in
you application code (one single step that is).  Now forget upright
and java.  Plug in a single step of a Scheme interpreter.  You've
got it?)  I did not dare to even try floats.  Too floating this ground.





___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag -- SORRY

[Jörg F . Wittenberger]

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 might
eventually remove the handle_interrupt at the begin of C_reclaim
completely if I could prove that running finalizers where I run
signal handlers right now would be a safe thing to do.)

Right now I'm running signal handlers from the scheduler as soon
as the yielding thread is where it belongs (ready queue or garbage).
That would be after the context switch.

But as I'm preparing this message I noticed that there's another badly
handles case in my code (EINTR translated into a thread-yield if I'm
correct).

However I need to remind you that I'm currently working from kinda
wild guess work.  I'm reading the code and docs I found so far.
(Giving priority to the way I understand the current code.)

And there is one more case where I might need some help.

A bad one in fact.

The whole s* works quite well with many threads.  However somehow I'm
missing the spot where I can hook into the execution right *after*
gc.  With threads: in ##sys#schedule in scheduler.scm without threads
I'm unsure.  As I read the source it should arrive in ##sys#schedule
too, but this time in library.scm.

However: there I called the signal handler too.

So far I have *not* made sure that it is not called.
But trying to stop chicken compiling itself by pressing C-c will be
ignored.

I know: this could have been a different reason.




___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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 C_interrupts_enabled is false, the entire routine is
> >contained in that if statement.
> >
> >My reading of that is that a signal being delivered when
> >C_interrupts_enabled is false wil cause that signal to be discarded.
> >
> >Yes?
> 
> Yes. That's what I've been talking about in the next paragraph.
> 
> With the changes I made (did I post them, did not I?) this problem is gone.
> 
> 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 I was really attending to this
conversation.  I can't find it in my archive.  Would you mind
sending it to me again?

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Jörg F . Wittenberger]

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.

During which time signals are really discarded?

As far as I read the source, the signal will be recorded, not discarded.



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 C_interrupts_enabled is false, the entire routine is
contained in that if statement.

My reading of that is that a signal being delivered when
C_interrupts_enabled is false wil cause that signal to be discarded.

Yes?


Yes. That's what I've been talking about in the next paragraph.

With the changes I made (did I post them, did not I?) this problem is gone.

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? ...




___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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 really discarded?
> 
> As far as I read the source, the signal will be recorded, not discarded.
> 

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 C_interrupts_enabled is false, the entire routine is
contained in that if statement.

My reading of that is that a signal being delivered when
C_interrupts_enabled is false wil cause that signal to be discarded.

Yes?

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Jörg F . Wittenberger]

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 recorded, not discarded.

Now this could run into the situation, that there would be several
signals (to be) recorded until they are handled.

This is exactly the situation my changes to the signal handler as
initially proposed recently would handle.  At least for MAX_INT many
signals (which, when pending, should bring your machine down in any case).


situation.  A lot of blood and tears were spilled over signal
handling on Unix to get to reliable signal delivery.  I don't think
Chicken should implement unreliable signal delivery on top of a
reliable mechanism.


That's what I've been asking lately: should we call the signal handler
once for every signal, or might it be better to change the signal handlers
signature to receive the number of times the signal has seen since
the signal handler was called last time.

NB: the former would be easy to implement on top of the latter.
The latter could be quite some overhead for no good reason.

Maybe the latter should be the default which can be changed by the user.

My current code however does the opposite: it deliberately calls the 
handler once per invocation using the old API. Thereby possibly ignoring 
signals (it discards and resets the counter. (I had not yet the time to 
write the code for the maybe-case and change the API) Since my code does 
not count the signals, it works well under this condition.





___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Jörg F . Wittenberger]

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.


Alaric, that's exactly the effect and reason why I'm using this
disable-interrupts/enable-interrupts around fork: to make sure
there is only this one Chicken-threads running in the child.
With interrupts disabled there is no scheduling in chicken.
(At least not until you run into a thread-yield! anyway.)

And therefore I'd really recommend to keep it in the runtime.


I think a better mechanism would be a way to abort all threads but the
current one, triggered after the fork in the child, with no interrupts
until the thread murder is complete.


True.

Though I view doing this as a higher level, complete solution.

And it depends on the ability to disable interrupts.  Given that we
can, we are free to choose an option:

A) Forget about all other chicken threads and just exec the code.
This is the vfork-then-exec case.  Chances are that this is, what
the doctor ordered in most cases.  (As it is in mine.)

B) Kill the threads and re-enable chicken's scheduler (aka
enable-initerupts).

(B) might need some more considerations.  I'm not sure how this could
be mapped to srfi-18.  I'll abstain from guess work here.


If you just go off and exec after the fork it'd be better to
uninterruptably vfork-then-exec, but we have procedures to do that already!

Aborting all threads but the one that asked for the fork also gives one
the opportunity to inform them of this fact, should any of them leave
useful data structures in incosistent states with locks held. There's
something to be said for requesting permission to fork from all threads
before doing so, so they can make sure they finish any operations on
shared state in the parent, but that'll be complex, and a potential
performance bottleneck, so probably not worth it!

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6EkCcACgkQRgz/WHNxCGoBNwCfS5syjjCVWFiyjcP0S6z/BFoB
s6MAnjE+v+0Tf32+9bQ+X6wd6UgEA+pA
=fjVS
-END PGP SIGNATURE



___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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, and this particular feature is at cross-purposes.
> 
> So it seems... Signals should always end up being handled somewhere,
> unlessly explicitly set to be ignored; in that case, ignoring it IS
> handling it, but not otherwise.
> 

I'll add too that signals have an API-level mechanism for ignoring
them, which we should probably use.  And yes.


> IIRC, signals are handled by setting a flag and poking the stack limit
> then returning. A GC is then invoked as soon as the interrupted thread
> tries to allocate memory, due to the poked stack limit, but the GC
> checks for the signal flag and goes off to do the signal if it has to.
> 
> I presume that invoking the Chicken runtime inside the C-level signal
> handler is unsafe on account of Chicken wanting to call non-signal-safe
> C functions.
> 

It would be something of a minor miracle were this not true.  I
think it is technically achievable, though I say that with zero
understanding of the actual effort involved.  It's more my ideal
case worth banging my head against a few times than something I
think we can do in practice.


> I presume that allocating memory in a Chicken-level signal handler is
> "risky" as you might have actually been at or near the stack limit when
> the signal happened.
> 
> I have not looked at the mechanism in code - just heard hearsay about it
> - - so please take this suggestion with a pinch of salt:
> 
> 1) Have a (signal-safe) data structure containing pending signals. This
> might just be a bitmask, or if we want to be flash, a queue of generic
> pending "software interrupts" if there's uses for it other than signals.
> 
> 2) C-level signal handlers poke an entry into the structure indicating
> the need to invoke a Chicken signal handler, and poke the stack limit
> 
> [all of the above is basically what I think we already have]
> 
> 3) The GC, invoked due to the stack limit being breached, checks for
> pending signals. If there are any, it resets the stack limit to what it
> was originally, then modifies the currently active continuation to a
> newly-allocated one that invokes a system procedure which executes all
> pending signals, then continues to the previous continuation; and returns.
> 
> The normal stack limit needs to be set so that there will always, in the
> worst case, be enough space to allocate that extra continuation frame.
> If the system WAS at the edge of the stack when the signal(s) came in,
> it would then still be able to allocate the special continuation;
> execution of it would then almost instantly trigger a perfectly ordinary
> GC, and execution would continue as usual, executing the pending signal
> handler(s) then continuing with user code as before.
> 

The Minix source code is illustrative on this point.  I think a
program being near the stack limit when a signal arrives is the only
time in that operating system that a process will be killed without
the normal mechanims the kernel goes through--It just tosses the
thing out.

I've never looked at how this behaves on *BSD or Linux, but I
imagine there is a similar condition (or as you outline above,
a reserve available).  So this comes up even in C, which at least
on Minux is not a handleable condition.

We effectively can't handle it if our GC makes a syscall--I imagine
that we minimally call sbrk() (or whatever the kids call it these
days) in the event of a full, post-GC heap.  That may well be a
terminal case in this rabbit hole, mirroring the terminal case in the
C code.


> That would give you low latency, unless the GC really needed to happen,
> in which case... well... it needs to happen before the handler can run.
> It would run signal handlers in the context of the currently executing
> thread when they happened, so to all intents and purposes it would be
> normal Chicken code, and the current thread would just temporarily dart
> off into signal handlers when required; I'm not sure what dynamic
> environment (in the parameters/current-output-port) they should be in;
> neither do I know how they are implemented in Chicken! Perhaps they
> should encapsulate a copy of the dynamic environment in place when the
> signal handler was registered, as the most hygienic option...
> 

I pretty much rely on my registered signal handler being in the
dynamic environment it was declared in.  The EINTR test case uses
this to get hold of a file descriptor created in the main thread. 


I'll add that we might of course get a signal while performing GC,
a case that needs to be accounted for.  And that we also *must* handle
deferred signals before making another syscall, whether that syscall
happened from user code or whether we're making a syscall in service
to 

Re: [Chicken-users] remove enable/disable interrupt flag

[Alaric Snell-Pym]

-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 Unix to get to reliable signal delivery.  I don't think
> Chicken should implement unreliable signal delivery on top of a
> reliable mechanism.

I quite agree.

> It seems that the thread-like nature of signal handling and the
> thread-like nature of threading have been intermixed in the
> scheduler, and this particular feature is at cross-purposes.

So it seems... Signals should always end up being handled somewhere,
unlessly explicitly set to be ignored; in that case, ignoring it IS
handling it, but not otherwise.

IIRC, signals are handled by setting a flag and poking the stack limit
then returning. A GC is then invoked as soon as the interrupted thread
tries to allocate memory, due to the poked stack limit, but the GC
checks for the signal flag and goes off to do the signal if it has to.

I presume that invoking the Chicken runtime inside the C-level signal
handler is unsafe on account of Chicken wanting to call non-signal-safe
C functions.

I presume that allocating memory in a Chicken-level signal handler is
"risky" as you might have actually been at or near the stack limit when
the signal happened.

I have not looked at the mechanism in code - just heard hearsay about it
- - so please take this suggestion with a pinch of salt:

1) Have a (signal-safe) data structure containing pending signals. This
might just be a bitmask, or if we want to be flash, a queue of generic
pending "software interrupts" if there's uses for it other than signals.

2) C-level signal handlers poke an entry into the structure indicating
the need to invoke a Chicken signal handler, and poke the stack limit

[all of the above is basically what I think we already have]

3) The GC, invoked due to the stack limit being breached, checks for
pending signals. If there are any, it resets the stack limit to what it
was originally, then modifies the currently active continuation to a
newly-allocated one that invokes a system procedure which executes all
pending signals, then continues to the previous continuation; and returns.

The normal stack limit needs to be set so that there will always, in the
worst case, be enough space to allocate that extra continuation frame.
If the system WAS at the edge of the stack when the signal(s) came in,
it would then still be able to allocate the special continuation;
execution of it would then almost instantly trigger a perfectly ordinary
GC, and execution would continue as usual, executing the pending signal
handler(s) then continuing with user code as before.

That would give you low latency, unless the GC really needed to happen,
in which case... well... it needs to happen before the handler can run.
It would run signal handlers in the context of the currently executing
thread when they happened, so to all intents and purposes it would be
normal Chicken code, and the current thread would just temporarily dart
off into signal handlers when required; I'm not sure what dynamic
environment (in the parameters/current-output-port) they should be in;
neither do I know how they are implemented in Chicken! Perhaps they
should encapsulate a copy of the dynamic environment in place when the
signal handler was registered, as the most hygienic option...

> -Alan

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6El54ACgkQRgz/WHNxCGpebACfdxF+Fqb3OiEVJHoAaww3U23f
inkAnRCPDl2dZhWrrdBODaBC8+rCDdHY
=VjKl
-END PGP SIGNATURE-

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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 the same with
> >> Chicken threads.
> >
> > Alaric, that's exactly the effect and reason why I'm using this
> > disable-interrupts/enable-interrupts around fork: to make sure
> > there is only this one Chicken-threads running in the child.
> > With interrupts disabled there is no scheduling in chicken.
> > (At least not until you run into a thread-yield! anyway.)
> >
> > And therefore I'd really recommend to keep it in the runtime.
> 
> I think a better mechanism would be a way to abort all threads but the
> current one, triggered after the fork in the child, with no interrupts
> until the thread murder is complete.
> 
> If you just go off and exec after the fork it'd be better to
> uninterruptably vfork-then-exec, but we have procedures to do that already!
> 
> Aborting all threads but the one that asked for the fork also gives one
> the opportunity to inform them of this fact, should any of them leave
> useful data structures in incosistent states with locks held. There's
> something to be said for requesting permission to fork from all threads
> before doing so, so they can make sure they finish any operations on
> shared state in the parent, but that'll be complex, and a potential
> performance bottleneck, so probably not worth it!
> 
> ABS
> 

In posix threads, this is what pthread_atfork() is for--to clean up
resources in the process of joining threads across a fork.

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 Unix to get to reliable signal delivery.  I don't think
Chicken should implement unreliable signal delivery on top of a
reliable mechanism.

It seems that the thread-like nature of signal handling and the
thread-like nature of threading have been intermixed in the
scheduler, and this particular feature is at cross-purposes.

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alaric Snell-Pym]

-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 reason why I'm using this
> disable-interrupts/enable-interrupts around fork: to make sure
> there is only this one Chicken-threads running in the child.
> With interrupts disabled there is no scheduling in chicken.
> (At least not until you run into a thread-yield! anyway.)
>
> And therefore I'd really recommend to keep it in the runtime.

I think a better mechanism would be a way to abort all threads but the
current one, triggered after the fork in the child, with no interrupts
until the thread murder is complete.

If you just go off and exec after the fork it'd be better to
uninterruptably vfork-then-exec, but we have procedures to do that already!

Aborting all threads but the one that asked for the fork also gives one
the opportunity to inform them of this fact, should any of them leave
useful data structures in incosistent states with locks held. There's
something to be said for requesting permission to fork from all threads
before doing so, so they can make sure they finish any operations on
shared state in the parent, but that'll be complex, and a potential
performance bottleneck, so probably not worth it!

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6EkCcACgkQRgz/WHNxCGoBNwCfS5syjjCVWFiyjcP0S6z/BFoB
s6MAnjE+v+0Tf32+9bQ+X6wd6UgEA+pA
=fjVS
-END PGP SIGNATURE-

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Jörg F . Wittenberger]

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 ((pid (begin
 (chicken-disable-interrupts!)
 ((foreign-lambda int "fork")) ))
(if (not (= pid 0)) (chicken-enable-interrupts!))
...
)

...

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 reason why I'm using this
disable-interrupts/enable-interrupts around fork: to make sure
there is only this one Chicken-threads running in the child.
With interrupts disabled there is no scheduling in chicken.
(At least not until you run into a thread-yield! anyway.)

And therefore I'd really recommend to keep it in the runtime.




___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alaric Snell-Pym]

-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
>  (chicken-disable-interrupts!)
>  ((foreign-lambda int "fork")) ))
> (if (not (= pid 0)) (chicken-enable-interrupts!))
> ...
> )

To be honest, doing *anything* between fork and exec is pretty
questionable. There's the big issue that threads might not be expecting
to be randomly duplicated by actions in some other thread, and proceed
to do something twice because of it (not a great issue if it's just
touching RAM, but a great issue if it involves I/O or mutual exclusion
mechanisms). Then there's the fact that you can't use vfork if you do
anything other than go straight into an exec, so you need to pay the
cost of duplicating the entire address space with CoW mappings (which
turned out to be a critical performance factor in a fork-heavy workload
here at work, recently!).

Having said that, there are good uses of fork() other than as a "vfork()
then exec()" pair; you just need to be VERY CAREFUL, and get
whole-program cooperation. Eg, don't initialise some third-party library
in the parent, then use it in the child; only take your own state across
the fork, and audit it for the consequences.

(Good uses of fork() I have seen include redis' technique of forking to
get an atomic copy of the process memory to snapshot to disk while the
parent continues to process updates, and software forking off its own
daemon processes as a form of threading or to ensure isolation from the
parent for security reasons! But all of these cases involve careful
consideration of the transmission of state from parent to child.)

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.

Chicken fork - no food jokes!

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6EiHIACgkQRgz/WHNxCGr0zwCfUWMseuGomWLBL/jgQGHUtEPE
RXkAn1C0eXxK1zfXgwfoCR4OFKstU7X2
=d9Ca
-END PGP SIGNATURE-

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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.  Is this code
> >actually used?
> 
> Be careful!
> 
> I found it to be win to actually reference and use that code.
> 
> I do lot's of process-fork.  The childs will soon be replaced
> by another program.  Why should they spend time in garbage collection
> before the exec call?  Futhermore it's dangerous to leave all
> threads enabled after a fork.  I've seen cases when those subprocess
> managed to write to file descriptors used by the parent.
> 
> That's one the the things on my list: find some better way to do
> the fork.  So far I do
> 
> (define-foreign-variable C_interrupts_enabled bool "C_interrupts_enabled")
> 
> (define (chicken-enable-interrupts!) (set! C_interrupts_enabled #t))
> (define chicken-disable-interrupts! (foreign-lambda void
> "C_disable_interrupts"))
> 
> (let ((pid (begin
>  (chicken-disable-interrupts!)
>  ((foreign-lambda int "fork")) ))
> (if (not (= pid 0)) (chicken-enable-interrupts!))
> ...
> )
> 
> 

I figured if someone was using this, it would be you!

Thank you for this use case.  I'll account for it now.

I withdraw this patch--I do consider this code broken--including the
test case above (it has a race condition where a signal might be
delivered before the fork but after the disable interrupts), though
this is not the only case in the signal handling code where this is
true.

I'll resubmit a new patch.

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Jörg F . Wittenberger]

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 reference and use that code.

I do lot's of process-fork.  The childs will soon be replaced
by another program.  Why should they spend time in garbage collection
before the exec call?  Futhermore it's dangerous to leave all
threads enabled after a fork.  I've seen cases when those subprocess
managed to write to file descriptors used by the parent.

That's one the the things on my list: find some better way to do
the fork.  So far I do

(define-foreign-variable C_interrupts_enabled bool "C_interrupts_enabled")

(define (chicken-enable-interrupts!) (set! C_interrupts_enabled #t)) 
(define chicken-disable-interrupts! (foreign-lambda void 
"C_disable_interrupts"))


(let ((pid (begin
 (chicken-disable-interrupts!)
 ((foreign-lambda int "fork")) ))
(if (not (= pid 0)) (chicken-enable-interrupts!))
...
)




I'm preparing a larger patch for the signal handling code, so
knowing whether this is used (and how) is important for getting
my next set of patches correct.

-Alan




___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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 larger patch for the signal handling code, so
> knowing whether this is used (and how) is important for getting
> my next set of patches correct.
> 
> -Alan
> -- 
> .i ma'a lo bradi cu penmi gi'e du

Let's attach the patch, shall we?  Reviewing this, I had to add a
thunk to the "C_fudge" routine, case 14.  It is not the least bit
obvious what that routine does, or how case 14 gets called.  What
is that?  It's the only part I don't consider straightforward, other
than my already mentioned use of this feature I'm not seeing.

diff --git a/chicken.h b/chicken.h
index 8c6eff3..1739fb9 100644
--- a/chicken.h
+++ b/chicken.h
@@ -1527,8 +1527,6 @@ C_fctexport C_word C_fcall C_callback_wrapper(void *proc, 
int argc);
 C_fctexport void C_fcall C_callback_adjust_stack(C_word *base, int size);
 C_fctexport void CHICKEN_parse_command_line(int argc, char *argv[], C_word 
*heap, C_word *stack, C_word *symbols);
 C_fctexport void C_fcall C_toplevel_entry(C_char *name) C_regparm;
-C_fctexport C_word C_fcall C_enable_interrupts(void) C_regparm;
-C_fctexport C_word C_fcall C_disable_interrupts(void) C_regparm;
 C_fctexport void C_fcall C_paranoid_check_for_interrupt(void) C_regparm;
 C_fctexport void C_zap_strings(C_word str);
 C_fctexport void C_set_or_change_heap_size(C_word heap, int reintern);
diff --git a/runtime.c b/runtime.c
index c0c91bc..980f303 100644
--- a/runtime.c
+++ b/runtime.c
@@ -331,7 +331,6 @@ C_TLS int
   C_gui_mode = 0,
   C_abort_on_thread_exceptions,
   C_enable_repl,
-  C_interrupts_enabled,
   C_disable_overflow_check,
 #ifdef C_COLLECT_ALL_SYMBOLS
   C_enable_gcweak = 1,
@@ -697,7 +696,6 @@ int CHICKEN_initialize(int heap, int stack, int symbols, 
void *toplevel)
   chicken_is_running = chicken_ran_once = 0;
   interrupt_reason = 0;
   last_interrupt_latency = 0;
-  C_interrupts_enabled = 1;
   C_initial_timer_interrupt_period = INITIAL_TIMER_INTERRUPT_PERIOD;
   C_timer_interrupt_counter = INITIAL_TIMER_INTERRUPT_PERIOD;
   memset(signal_mapping_table, 0, sizeof(int) * NSIG);
@@ -2669,7 +2667,7 @@ C_regparm void C_fcall C_reclaim(void *trampoline, void 
*proc)
 
   /* assert(C_timer_interrupt_counter >= 0); */
 
-  if(interrupt_reason && C_interrupts_enabled)
+  if(interrupt_reason)
 handle_interrupt(trampoline, proc);
 
   /* Note: the mode argument will always be GC_MINOR or GC_REALLOC. */
@@ -4102,8 +4100,9 @@ C_regparm C_word C_fcall C_fudge(C_word fudge_factor)
   case C_fix(13):  /* debug mode */
 return C_mk_bool(debug_mode);
 
+  /* XXX: Where is this called from, how do we deprecate it? */
   case C_fix(14):  /* interrupts enabled? */
-return C_mk_bool(C_interrupts_enabled);
+return C_mk_bool(1);
 
   case C_fix(15):  /* symbol-gc enabled? */
 return C_mk_bool(C_enable_gcweak);
@@ -4244,34 +4243,16 @@ 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;
+  saved_stack_limit = C_stack_limit;
 
 #if C_STACK_GROWS_DOWNWARD
-C_stack_limit = C_stack_pointer + 1000;
+  C_stack_limit = C_stack_pointer + 1000;
 #else
-C_stack_limit = C_stack_pointer - 1000;
+  C_stack_limit = C_stack_pointer - 1000;
 #endif
 
-interrupt_reason = reason;
-interrupt_time = C_cpu_milliseconds();
-  }
-}
-
-
-C_regparm C_word C_fcall C_enable_interrupts(void)
-{
-  C_timer_interrupt_counter = C_initial_timer_interrupt_period;
-  /* assert(C_timer_interrupt_counter > 0); */
-  C_interrupts_enabled = 1;
-  return C_SCHEME_UNDEFINED;
-}
-
-
-C_regparm C_word C_fcall C_disable_interrupts(void)
-{
-  C_interrupts_enabled = 0;
-  return C_SCHEME_UNDEFINED;
+  interrupt_reason = reason;
+  interrupt_time = C_cpu_milliseconds();
 }
 
 
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] remove enable/disable interrupt flag

[Alan Post]

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 is used (and how) is important for getting
my next set of patches correct.

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users