This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
On 23 Dec 2003 13:34:53 -0500, Jim Blandy <jimb@xxxxxxxxxx> wrote:
felix <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:As the document correctly points out, calls from Scheme to C can be a lot more efficient, if it is known that callbacks into Scheme do not occur. This applies to Chicken (for example), where all sorts of weird things happen in such a case. So, here I'm down on my knees, *begging* for separate forms of Scheme->C calls that forbid callbacks. This also simplifies the case when threads are involved (if thread-switches can only occur in Scheme code). Note that Scheme->C calls outnumber Scheme->C->Scheme ones usually by a large amount.Could you give details about the sorts of optimizations this information enables?
Chicken for example uses the C-stack as the first generation of a generational GC scheme (as described in Henry Baker's Cheney-on- the-MTA paper). Calling C from Scheme is no problem, if the code returns properly, but a callback/GC would possibly invalidate the portion of the stack below the currently pending C stack-frame, and uncontrolled shrinking of the nursery would quickly result in problems. To prevent this, the nursery (1st gen. / C-stack) has to be resized, by pulling out live data (and cleaning up the nursery) before calling the Ccode, and then setting the "watermark" that marks the lower end of the stack. One method would be to simply disallow callbacks (as Baker proposes in his paper), but we don't want that, of course...
Another issue is threads: the blocking behaviour mentioned in SRFI-50 on returning from callbacks would not have to be checked, if it is known that the invocation of C from Scheme has no chance of calling back into Scheme. cheers, felix