[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