[gambit-list] Strange Gambit error problems DS

Marc Feeley feeley at iro.umontreal.ca
Fri Oct 27 10:23:39 EDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27-Oct-06, at 8:55 AM, Andrew Lentvorski wrote:

> I don't understand why assigning to the interrupt vector would make  
> it work though--very strange.
>

Because the default setting of the interrupt vector calls the  
scheduler, which calls ___device_select to see if any devices are now  
ready to do I/O (i.e. they have unblocked), and the corresponding  
thread has to be resumed.  When you redirect the heartbeat interrupt  
vector you are bypassing the scheduler.

> Is there anything else I need to implement before I start in on the  
> networking stuff?

Not that I can think of.  But remember that to have a non-blocking  
thread system the I/O needs to be non-blocking, which means you will  
have to implement ___device_select properly.  This is done with  
"select" on POSIX systems, and "MsgWaitForMultipleObjects" on WIN32.   
Now given that you are on a dedicated system, the simplest approach  
may be to just poll each device until one unblocks (this uses 100% of  
the CPU, but the CPU would not be doing anything else, unless it can  
power-down to save power).  Anyway, keep this in mind.  Each class of  
I/O device has a "select" method that interfaces to the  
implementation of ___device_select.  On a call to the read and write  
methods, the device can indicate that the I/O would block (return  
code = EAGAIN).  In that case the Gambit scheduler will suspend the  
calling thread and remember that device for future calls to  
___device_select (which will occur either on a heartbeat interrupt or  
when all threads are blocked on I/O).  When ___device_select is  
called, the "select" method of each blocked device is called to setup  
the required data structures needed by select/ 
MsgWaitForMultipleObjects/other, then ___device_select calls select/ 
MsgWaitForMultipleObjects/other, and then calls the "select" method  
of each blocked device again so that it can check if the device has  
unblocked or not.  To simplify the implementation of  
___device_select, you should find an IP stack that supports  
multiplexed I/O, for example Tiny TCP has a sock_poll function to do  
this (I don't know if lwIP has this).

On a related note, I was supervising a student over the summer whose  
project was to write a compact IP stack in Scheme (sufficiently  
compact to fit on a microcontroller).  Parts of it are working, so  
you may want to contact her to get more information on the state of  
the stack (Lysiane Bouchard, bouchardl at iro.umontreal.ca).  This may  
be a good alternative if you can't adapt a good IP stack for the  
Nintendo DS.

Marc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFQhZr//V9Zc2T/v4RAtihAJ4o9lenlClW8Q5hL4MAmJZVyftbpACfdk+e
IjZOWrgFrREeeqlUedkodFk=
=HGXY
-----END PGP SIGNATURE-----



More information about the Gambit-list mailing list