On 2008-10-27, MacArthur, Ian (SELEX GALILEO, UK) <[EMAIL PROTECTED]> wrote: > >> >> In my multiplatform apps, I made the decision to use an #ifdef >> to resolve threading, using pthreads for unix code, and >> the win32 >> CreateThread() for Windows, which is very easy to use >> and works fine. >> (More than I can say about a lot of other WIN32 API >> functions..!) >> >> I hadn't heard of _beginthread().. interesting. Docs here: >> http://msdn.microsoft.com/en-us/library/kdzttdcb(VS.80).aspx >> >> Note the docs for _beginthread() are recommending >> to use the safer "_beginthreadex()" which is apparently >> (trying not to giggle) a 'thread safe' version of that >> call.. %^D > > > Yes - I wouldn't bother too much about "_beginthreadex()" to be honest. > It's main "advantage" over the "plain" _beginthread(), as far as I can > see, is that it has the same parameters (give or take some minor casts) > as the older CreateThread() function, so it is fairly easy to drop that > in to old code that used CreateThread() before. > > For new code, I would always choose _beginthread() in preference, and it > has the added advantage (from my perspective) of being more like > pthread_create() and thus easier to ifdef into place... > > As for CreateThread(), I'd advocate against using it at all. Even the MS > docs recommend against it these days. It seems there are issues with the > way it interacts with the C runtime in threaded apps that can be > "problematic". > Although why they would have a CreateThread API that didn't work in > threaded apps is an interesting question... > > That said, I have never knowingly encountered a bug due to > CreateThread() failing to interact correctly with the C runtime, but > when even MS are advising against it... Well, caution to the fore - use > beginthread, I say!
BUT - I use Fl::lock() and friends a lot because i have a "MIDI receiver thread" that runs all the time and updates the UI on incoming messages. Now, the doc sais, to be able to use those functions FLTK needs to be built with --enable-threads which in turn relies on pthreads. So, as far as i understand it, in my case, i have to use a pthread lib for windows. Right? If not, that would be great and i would prefer some #ifdefs too. ") For now i got pthreads-win32 http://sourceware.org/pthreads-win32/ and successfully built FLTK against it (i had to add a check for -lpthreadGC2 in configure.in). Now i wonder: both, FLTK and my app use the pthread lib. If i wanted it to be linked statically, i would do that when i build my app, not FLTK, right? Will FLTK then know that the lib has been linked into my app? I wonder because FLTK was linked against the dll in the first place. thank you, jan _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
