Your caller uses threads, that is where you should worry about threadsafety. It really is an easy concept to grasp.
Use a mutex from the caller as shown in the doc and you'll never have an error, regardless of the dll being compiled threadsafe or not.
Btw: Just check threadsafe on your caller program and see what you get.
dll question?
-
netmaestro
- PureBasic Bullfrog
- Posts: 8452
- Joined: Wed Jul 06, 2005 5:42 am
- Location: Fort Nelson, BC, Canada
Netmaestro, it's a really easy concept to grasp, but I think you need Fred to tell you nevertheless. It's pointless to argue with me anyways because I am so stubborn and think I right. Which I of course have 
In fact you even said it yourself: that's a bug in threadsafe.
That's because threadsafe is broken. It really shouldn't be that. And here we don't have to wait for Fred to post in this thread, just look here: http://www.purebasic.fr/english/viewtopic.php?t=22320Btw: Just check threadsafe on your caller program and see what you get.
In fact you even said it yourself: that's a bug in threadsafe.
-
netmaestro
- PureBasic Bullfrog
- Posts: 8452
- Joined: Wed Jul 06, 2005 5:42 am
- Location: Fort Nelson, BC, Canada
Whoa, didn't expect this many replies! 
Thanks guys.
It's got me a thinking this has.
The jury has returned though and I've got to side with Trond here, although I can't get your example to crash when the dll is compiled without thdsafe and the calling app is thdsafe etc!
By virtue of the fact that the dll in question is using it's own global variables means that any thread created by the main app and calling functions within the dll has the potential to alter these globals and cause untold havoc! Of course this is a separate problem from being threadsafe because, as netmaestro points out, this problem would not be addressed by making the dll threadsafe. However, the damn strings problem is another matter I guess!
So it's a matter of getting PB to behave itself when compiling the dll with the threadsafe switch and doing something about these globals; either mutexes or thread local storage.
Thanks again, this has been an interesting read.
Still puzzled though why Trond's example does not crash on my system?
@netmaestro: yea I need a larger shirt to cover the bellybutton! As for the hole in my trousers...
Thanks guys.It's got me a thinking this has.
The jury has returned though and I've got to side with Trond here, although I can't get your example to crash when the dll is compiled without thdsafe and the calling app is thdsafe etc!
By virtue of the fact that the dll in question is using it's own global variables means that any thread created by the main app and calling functions within the dll has the potential to alter these globals and cause untold havoc! Of course this is a separate problem from being threadsafe because, as netmaestro points out, this problem would not be addressed by making the dll threadsafe. However, the damn strings problem is another matter I guess!
So it's a matter of getting PB to behave itself when compiling the dll with the threadsafe switch and doing something about these globals; either mutexes or thread local storage.
Thanks again, this has been an interesting read.
Still puzzled though why Trond's example does not crash on my system?
@netmaestro: yea I need a larger shirt to cover the bellybutton! As for the hole in my trousers...
I may look like a mule, but I'm not a complete ass.