[gambit-list] Embedding swank-gambit

Roger Wilson misterrogerwilson at gmail.com
Mon May 23 17:36:02 EDT 2011


On Mon, May 23, 2011 at 9:41 PM, Marc Feeley <feeley at iro.umontreal.ca>wrote:

>
> On 2011-05-23, at 3:40 PM, Roger Wilson wrote:
>
> > I'm evaluating using Gambit-C Scheme as a scripting type language within
> my application.  The main app is written in C++ and I've got the C++ ->
> Scheme -> C++ calls all working.  That was all straightforward and I'm
> pretty happy with that.  I'm now trying to integrate swank and have hit a
> bit of a dead end.  I can run swank-gambit on its own and it just worked,
> the problem has come trying to run it  alongside the thread that
> communicates with the host C++ app.  I've tried replacing the code at the
> bottom of swank-gambit.scm with the following based on the iOS sample.  This
> creates a new thread that returns to the C++ host, while the primordial
> thread creates the swank server.
> >
> > (continuation-capture
> > (lambda (cont)
> >    (thread-start!
> >     (make-thread
> >      (lambda ()
> >        (continuation-return cont #f))))
> >
> >    ;; the primordial thread is running this...
> >    (swank-server-register!)
> >    (thread-sleep! +inf.0)
> >
> >    exit)))
> >
> >
> > That works in as much as it creates the tcp listen port and slime can
> connect to it, however it seems that the connection is rarely if ever
> serviced.  The calls between C++ and Scheme in the other thread all continue
> ok.  Can someone point me in the direction I need to fix this please?  I
> suspect I've got a fundamentally wrong understanding of swank or the whole
> Gambit threading model.  Do I somehow need to provide execution time to the
> primordial thread?
> >
> > Roger.
>
> Gambit implements green threads, and this may be the cause of your problem.
>  If you use the FFI to call a C++ function that blocks, or if your main
> function in C++ blocks and only calls the Scheme code occasionally (for
> example when there is a GUI event), then the context switching of the Scheme
> threads will not happen and your Scheme threads will not get to run (even if
> they are conceptually runnable).
>
> To circumvent this problem here are a few suggestions:
>
> 1) Call the following function regularly from your C++ code:
>
> (c-define (heartbeat) () void "heartbeat" "extern"
>  (##thread-heartbeat!))  ;; make sure other threads get to run
>
> This can be done by creating a timer on the C++ side which will generate an
> event that your main loop uses to call the heartbeat function.  That is what
> the examples/iOS example does, with the added feature that the timer events
> will be generated at a higher frequency when there are runnable Scheme
> threads, and slowly when there are none.
>
> 2) Some GUI libraries have an "idle" event that serves a similar purpose.
>
> 3) Run the Scheme code in a different OS thread, and communicate with it
> using a socket.
>
> 4) Rewrite your application so that the main function is in Scheme, and
> write your main loop in Scheme.  This is possible in some situations, such
> as when using X11 because the events are delivered on a socket (the X11
> "connection") which you can wait on with "##device-port-wait-for-input!".
>  See the directory examples/Xlib-simple for an example.
>
> Marc
>
>
Option1) is most appropriate for me and it's all working now.

Thanks,
Roger.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20110523/8999f9f7/attachment.htm>


More information about the Gambit-list mailing list