In BlitzMax the simplest solution I've found is to make your program reentrant and have it run itself which gives you a nice safe multiprocess environment.
The FreeAudio module starts up a thread in the Linux implementation so if you want to write drivers for external engines you can easily add threading to the native glue you write for the module as the toolchain is all setup to support the pthread model.
I don't think BlitzMax itself will get multi threading until it gets multi processor support.
Currently BlitzMax IS NOT THREAD SAFE and hence BRL do not support or advise any attempts that could see blitzobjects changing reference in anything but the core thread of the process.
I thought I knew everything about threads until hyperthreading came out for the P4 and the idea that every clock cycle multiple processors are contributing to the state of the machine is just daunting (code that is safe in preemptive scheduling will explode instinctively when placed in a parallel scheduled environment).
The FreeAudio module starts up a thread in the Linux implementation so if you want to write drivers for external engines you can easily add threading to the native glue you write for the module as the toolchain is all setup to support the pthread model.
I don't think BlitzMax itself will get multi threading until it gets multi processor support.
Currently BlitzMax IS NOT THREAD SAFE and hence BRL do not support or advise any attempts that could see blitzobjects changing reference in anything but the core thread of the process.
I thought I knew everything about threads until hyperthreading came out for the P4 and the idea that every clock cycle multiple processors are contributing to the state of the machine is just daunting (code that is safe in preemptive scheduling will explode instinctively when placed in a parallel scheduled environment).