On 5-Sep-08, at 7:31 AM, Mikael More wrote:
Then, there is one more relevant design aspect to Gambit here, that neither the manual nor the mailing list afaik has addressed:
Must c-lambda:s be returned in the exact inverse order as they were invoked, or can they be returned in other orders also?
This is addressed in section 19.7 of the Gambit manual. Note that to get a different order than the normal stack like behavior you need to use Scheme continuations (I view try/catch and setjmp/longjmp as stack like).
Whether this is so or not has great impact on how code that combines use of threads and/or closures and/or continuations with c-code that calls Scheme.
An example where it would have impact: Start two threads that invoke the example procedure a above an unlimited number of times, i.e.,
(define (spawn-a) (thread-start! (make-thread (lambda () (let loop () (a) (loop)))))) (define first-thread (spawn-a)) (define second-thread (spawn-a))
At some point, this will happen:
- a is invoked in the first thread. construct_my_returnvalue is
entered in the first thread. 2. The scheduler switches current thread of execution from the first thread to the second thread. 3. a is invoked in the second thread. construct_my_returnvalue is entered in the second thread. 4. The scheduler switches current thread of execution from the second thread to the first thread. 5. construct_my_returnvalue returns in the first thread. a returns in the first thread.
Is Gambit designed in a way that allows this?
No Gambit does not support this, because all of the code is executed in a single native thread.
If not, what do you consider the best strategies to safeguard against this ever happening?
The one that works for me is to constrain your code so that a single Scheme thread is allowed to do Scheme to C calls that contain C to Scheme calls (and possibly deeper). There can be an arbitrary number of threads doing Scheme to C calls without nested C to Scheme calls.
If it is, how are C frames rewinded? In the example above, right after a returns at 5., will its C frame be freed, or will this happen first when the C frame allocated in 3. is freed also?
Marc or anyone who knows, how does Gambit work in this respect?
Mikael
To support unrestricted Scheme to C to Scheme calls, Gambit would need to use several native threads. I'm considering this, but I haven't yet committed to make it happen.
Marc