[Chicken-users] Question again on heap mutation from signal handlers.

[Jörg F . Wittenberger]

Kon (or maybe Felix)

On Sep 1 2011, Kon Lovett wrote:


Probably of no use to you but … When I added all the extra unix
(Chicken v2 I think) signals stuff I figured (ha) that a Scheme
signal handler could only perform operations that accessed existing
structures, no heap mutation. I used handlers that basically only
set flags.


Is there a way to verify that signal handlers can not allocate
on the heap?

As far as I understand runtime.c this should be true.
But it's fairly complicated to reason here.
It would be very, very helpful to be sure about that one.

Since my eat-all-mem issue was gone all too suddenly with yet
another git update (the one with the larger update to types.db),
I'm afraid it might be a false positive.

And there are the downsides of the approach I've take to
get around this (possibly fake) issue.  Not only makes
it the interrupt latency a little larger (since what it tries
to do is to wait for gc to finish); I've used to have a signal
handler, which would write a thread listing into the log file.
This has been extraordinary reliable even when I managed to
mess up the thread system.  No longer avail.

Now I tried to re-enable the old handler invocation to confirm
that the old issue would come back.
So far it did not - which is confusing.

Thanks a lot

/Jörg




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

Re: [Chicken-users] Question again on heap mutation from signal handlers.

[Jörg F . Wittenberger]

On Oct 2 2011, Jörg F. Wittenberger wrote:


Kon (or maybe Felix)

On Sep 1 2011, Kon Lovett wrote:


Probably of no use to you but … When I added all the extra unix
(Chicken v2 I think) signals stuff I figured (ha) that a Scheme
signal handler could only perform operations that accessed existing
structures, no heap mutation. I used handlers that basically only
set flags.


Is there a way to verify that signal handlers can not allocate
on the heap?

As far as I understand runtime.c this should be true.
But it's fairly complicated to reason here.
It would be very, very helpful to be sure about that one.

Since my eat-all-mem issue was gone all too suddenly ...
Now I tried to re-enable the old handler invocation to confirm
that the old issue would come back.
So far it did not - which is confusing.


To summarize: no reason for confusion: so far meant: about 20
min. trying to force it.  Sometimes it's easier to just wait :-/

At least it reduces confusion.  A bit, that is.

If I could knew for sure that signal handlers may not touch the heap,
I would know that the approach to accept the higher latency in exchange
for the more natural coding of signal handlers would be worth the
time.

Alan: DON'T enable the normal signal handling.  It might work some
seemingly infinite time.  But eventually goes into EAM mode.
No theory why; just observation so far.

/Jörg


PS: If it eventually turns out to be true that the signal handler
has been the issue I had.  Plus it would turn out to be verifiable
that always running with interrupts disabled does not eventually
harm normal behaviour.  ...  THEN I'd call that a productive time!
We could leave quite some code with the garbage collector.




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