On 1 Jun 2012, at 22:59, Greg Ercolano wrote: > On 06/01/12 14:33, Ian MacArthur wrote: >> >> I was under the impression that it would play fine with pthreads, >> if you made at least one (possibly dummy) NSThread first, just to >> "wake up" the thread safe mechanisms > > Yes, that is true and is one of the two approaches > we can use. The STR goes into the details. > > I was thinking the 'correct' approach would be to use > Apple's native NSThread library in our Fl_cocoa.mm code. > > But if that turns out to be bumpy, the approach you mention > is surely the easier of the two to implement. > > One reason that might be necessary; the code uses pthread_join() > which might not have an NSThread equivalent. > > Here's the thread features the add_fd() code currently uses > on the mac (cocoa and carbon): > > mutex lock/unlock > pthread_create > pthread_cancel > pthread_join > > The thread cancel stuff is used by the destructor code > to ensure any child thread started is stopped. 'join' > is used to wait for completion.
Yup - that would be my worry though; we need to join so we can wait for the worker thread expiring... But will that play well mixing pthreads and NSThread's...? I just don't know (though on OSX it is entirely possible the NSThread and pthread have a common underlying implementation of course, I guess... > > This can perhaps be done differently with NSThread, > but sometimes it's better to change less code than to > be 'native'. > > Wasn't sure on this, which is why I seek Manolo's input, > as he's probably the most familiar with the NSThread stuff. Seems like a sound idea! Cheers, -- Ian _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
