Re: Re: Help with callbacks

>This is probably it then as both the timer and the thread callback 
>fail (The thread callback is definitely called from a foreign 
>thread). When you say "Lisp code may never be called on a thread", 
>do you mean that an unknown foreign thread may never call a Lisp 
>function, or that a Lisp function may never call an unknown thread 
>(or both)?

Both. Lisp code can only be executed by threads which are known by the lisp system. The reason is that garbage collection can be triggered at any time, by any thread. If this happens, only threads known to the garbage collector get scanned. If any lisp code is running on a thread not known to the collector, it will not be properly updated, which is usually fatal to that thread.


>Unfortunately calling BlessThread is not possible... Well, I suppose 
>it is, it would just mean wrapping the BlessThread/UnBlessThread 
>calls within #ifdef CORMAN_LISP and having the changes added to the 
>main SDL source tree.

If you have a native DLL (compiled in C or C++, for example) you can put code in the DllMain function which calls BlessThread() whenever a new thread is instantiated. One of the nice things about Win32 is that every time a new thread is created or destroyed, your DLL has a chance to take some action. The event is DLL_THREAD_ATTACH. Since it actually gets called by the new thread, it can do any thread-local stuff, and call any functions it needs to. To be complete, it should call UnblessThread() when called for the DLL_THREAD_DETACH event.

If you build a DLL using Corman Lisp, it automatically includes this functionality. So even though you may have another component actually doing a thread pool, and allocating and freeing threads, you should still be able to make that work by this method. Of course, if thread allocation and freeing happens fast and often, the performance penalty may be large (BlessThread() involves copying a whole bunch of bindings, and allocating some space) and it may not be the best solution. However, most good applications in Win32 don't do this--they allocate a pool of threads and only free or create them occasionally as needed.

All SDL calls use the C calling convertion, even the callbacks. My 
>FFI definitions use:
>
>#! (:export t :library "SDL" :ignore "DECLSPEC" :pack 4)
>
>The callback is defined using ct:defun-c-callback, which pretty much 
>covers the C calling convertion, correct ?

Yes.

Roger


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Looking for the latest Free IT White Papers?
Visit SearchMobileComputing.com to access over 500 white papers.
Get instant access at SearchMobileComputing.com Today
http://us.click.yahoo.com/9lAzoD/PLNGAA/witMAA/SyjtlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/