threading and 3rd party modules

BlitzMax Forums/BlitzMax Programming/threading and 3rd party modules

Johnsprogram(Posted 2011) [#1]
I'm building an application that will have one thread object for constantly updating the status of the musical tracks being played. This is so I could play the intro track only once and then play and loop the second track without "gaps."

However, I'm using a third-party module for reading XML files. When I build my application with "threaded build" checked, I keep getting an error saying that it can't locate the XML module. On the flip side, when the "threaded build" was unchecked and then build, there was no errors.

Here's my question: can I build threaded applications when I'm using third-party modules? If not, how come?


jsp(Posted 2011) [#2]
You need to build modules with "threaded build" checked, before you can use it in your app.


ima747(Posted 2011) [#3]
That check mark for treaded build flips a switch that basically ignores everything that isn't compiled for threading (i.e. all your modules that are only built in non threaded mode). As jsp said, you need to build any modules you're using (in addition to the standard modules that make up BMX that you're using) in threaded mode to get a threaded version of them. If you're using the default IDE, again as JSP said, turn on threaded mode and rebuild your modules. This should build a threaded version (since threaded mode is on) of your mods.

Bear in mind, as with all threading projects, that not everything can be legally executed from a child thread, and resources must be share politely if they are going to be accessed by more than 1 thread. Not knowing specifically what you plan, a couple things you might run into are
1) You can't update the UI, or draw safely from a child thread (graphical commands in bmax are, for all intents, limited to the main execution thread, with the notable exception of managing pixmaps since those are memory resident and are just technically data blocks)
2) I don't believe the audio systems are thread safe, so accessing them at all may cause some issues (e.g. checking the progress of the audio track)
3) Threading induces a fair whack of overhead for the application (as it has to manage the threads in addition to executing the code in each). On single core systems this can induce some performance hiccups.


Johnsprogram(Posted 2011) [#4]
Thanks for the warnings, ima747. I have tested the audio threading out. It seems to work, but it really draws out the performance of my application.