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
