I think this is an promising idea.
In fact I myself investigated possible threading schemes that would not have the major drawbacks of mainstream threading APIs (mainly, that the default for a thread is to share all the data with other threads, which is a synchronization nightmare and just doesn' makes sens).
The message passing scheme is precisely one of my favorites.
However the main problem in a language like BlitzMax is very likely to be with any code that has global side effect. It's one thing to forbid access to global variables from threads, it's another to forbid access to functions like Print. But if you don't, you aren't any safer. What happens if two threads call Print simultaneously? Or more generally, what happens if they call functions that access global variables or worse, call C code that is not thread safe ?
The very problem of most thread APIs comes from the language: if the language allows unrestricted side-effect (that is, any mainstream language) then threading secrity simply cannot be guaranteed by the language itself, and all the burden goes to the programmer. Current threading handling is really primitive, it's a bit like looking at assembly code when you know higher level languages. No in fact it's worse, I can enjoy assembly programming, but I hate threading APIs.
EDIT: alternatively, if serializing was implemented by a standard blitzmax module, this could be used to pass copies of practically *any* object to the threads (with the only drawback that you'd have to be very carefull no to pass huge graphes of objects this way, as serializinf is recursive).
In fact I myself investigated possible threading schemes that would not have the major drawbacks of mainstream threading APIs (mainly, that the default for a thread is to share all the data with other threads, which is a synchronization nightmare and just doesn' makes sens).
The message passing scheme is precisely one of my favorites.
However the main problem in a language like BlitzMax is very likely to be with any code that has global side effect. It's one thing to forbid access to global variables from threads, it's another to forbid access to functions like Print. But if you don't, you aren't any safer. What happens if two threads call Print simultaneously? Or more generally, what happens if they call functions that access global variables or worse, call C code that is not thread safe ?
The very problem of most thread APIs comes from the language: if the language allows unrestricted side-effect (that is, any mainstream language) then threading secrity simply cannot be guaranteed by the language itself, and all the burden goes to the programmer. Current threading handling is really primitive, it's a bit like looking at assembly code when you know higher level languages. No in fact it's worse, I can enjoy assembly programming, but I hate threading APIs.
EDIT: alternatively, if serializing was implemented by a standard blitzmax module, this could be used to pass copies of practically *any* object to the threads (with the only drawback that you'd have to be very carefull no to pass huge graphes of objects this way, as serializinf is recursive).