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