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