gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Running tasks on the background for streaming applications?

#160340 - ragefury32 - Mon Jul 14, 2008 6:08 am

Okay - so I have figured out (somewhat) of how to use WifiAutoConnect to make a connection via DSWifi, but I am having problems with one aspect of socket programming in the DS - how to create a background task.

So let me explain what I am trying to do - I am trying to hit a web service with a parameter, something like:
GET webapp/dynamic/streamlocations?userid=1123

And it'll push me a set of values automatically once every second until I close the connection.

Here's the question - how would I make the NDS automatically retrieve this information, store it, and allow other things to happen? I mean, I could make a timer interrupt on the NDS end wake up every second or so, do a connect() and retrieve the results, but the data is already automatically streamed to me. Is there a way to have something in the background pick up the data off a stream without intervention?

#160358 - JYC376 - Mon Jul 14, 2008 3:40 pm

If you mean multithreading, here are some options:

MTClib
Hermes' sound and multithreading lib

#160361 - Maxxie - Mon Jul 14, 2008 4:08 pm

ragefury32 wrote:

Here's the question - how would I make the NDS automatically retrieve this information, store it, and allow other things to happen? I mean, I could make a timer interrupt on the NDS end wake up every second or so, do a connect() and retrieve the results, but the data is already automatically streamed to me. Is there a way to have something in the background pick up the data off a stream without intervention?


Have one receiving socket open, have a select(set with timeout=0) to check non blocking whether or not data was received on this connection regulary and in the meantime, do whatever you want.

No need to open/close connection every time.
_________________
Trying to bring more detail into understanding the wireless hardware

#160364 - elwing - Mon Jul 14, 2008 4:21 pm

just a small offtopic question, that don't fill the multithreading level you need for networking, but does someone already tryed to play with protothread for their main gaming loop?

protothread

#160382 - tepples - Mon Jul 14, 2008 9:32 pm

elwing wrote:
protothread

Cooperative multithreading might become viable once devkitARM and libfat support non-blocking I/O. I've seen libfat block for five seconds at a time in some cases.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#160388 - josath - Mon Jul 14, 2008 11:09 pm

tepples wrote:
elwing wrote:
protothread

Cooperative multithreading might become viable once devkitARM and libfat support non-blocking I/O. I've seen libfat block for five seconds at a time in some cases.


solution is to stop using the G'n'M card? or are you simply referring to the lag when many drivers are compiled in and it's trying to scan them all? (which only happens if a user didn't apply a DLDI patch)

#160390 - Maxxie - Mon Jul 14, 2008 11:22 pm

josath wrote:
solution is to stop using the G'n'M card? or are you simply referring to the lag when many drivers are compiled in and it's trying to scan them all? (which only happens if a user didn't apply a DLDI patch)


The speed of the device doesn't really matter.
It will allways have a size dependand speed difference against a non blocking call.

The solution for me was to split the needed reads in very small slizes. Something i would like to avoid with non blocking IO calls.
(And this was on a much faster card then the GnM on an r4ds )
_________________
Trying to bring more detail into understanding the wireless hardware

#160400 - tepples - Tue Jul 15, 2008 3:07 am

josath wrote:
solution is to stop using the G'n'M card?

If only I could get my users to do the same...

Quote:
or are you simply referring to the lag when many drivers are compiled in and it's trying to scan them all? (which only happens if a user didn't apply a DLDI patch)

The latter. Even when I use the automatic DLDI patch of the R4 firmware, libfat's fatInitDefault() still appears to scan for an FCSR image on the cart in my DS's SLOT-2.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.