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

Reply via email to