   use-and-forget pthreads for a cross-platform library implementation?
  I'm used to using Win threads; however, in this case I'm working on a library that can be used across all platform. To add some spark to it, I'd like to fork some calculations and from what I've been reading, pthreads seems to be the most lightweight and intuitive approach.Now, ideally I'd prefer a true use-and-forget scenario: add a static link pthreads library to my own library and be done with it. However - seeing as a static library implementation of pthreads isn't available directly for download (or quite possibly my Googling sucks) and there's a specific Win version, which runs from a DLL, I find myself a bit confused as to how to go about cross-platform threading in the simplest possible way.Note that I have zero experience with cross-platform development and even though I don't have the possiblity of testing my code on other platforms and could get away with Win threads for now, I'm a bit curious how this is done in general.If someone can explain the pthreads-related bits I'm missing or link me to some page that does what I explained, I'd appreciate it a lot!   
Quote:Original post by irreversibleI'm used to using Win threads; however, in this case I'm working on a library that can be used across all platform. To add some spark to it, I'd like to fork some calculations and from what I've been reading, pthreads seems to be the most lightweight and intuitive approach.Now, ideally I'd prefer a true use-and-forget scenario: add a static link pthreads library to my own library and be done with it. However - seeing as a static library implementation of pthreads isn't available directly for download (or quite possibly my Googling sucks) and there's a specific Win version, which runs from a DLL, I find myself a bit confused as to how to go about cross-platform threading in the simplest possible way.Note that I have zero experience with cross-platform development and even though I don't have the possiblity of testing my code on other platforms and could get away with Win threads for now, I'm a bit curious how this is done in general.If someone can explain the pthreads-related bits I'm missing or link me to some page that does what I explained, I'd appreciate it a lot!You could try boost threads (I seem to be saying this a lot lately!). The concepts it exposes are very similar to pthreads, but are C++-ized. It *might* be more straight forward to extract the relevant boost thread source files if you really want to bundle a threading backend with your code.Personally though, I would just say "depends on XYZ threading package" and wouldn't bother bundling anything.   ;  I've been working with both Boost.Thread and pthread and would highly recommend Boost.Thread. Simply because it's much more comfortable to work with and a real fire-and-forget solution when it comes to cross-platform compatibility.A light-weight alternative would be the use of the OpenMP compiler extensions. Those work quite well for simple parallelization tasks and are supported by most of the mainstream compilers today.   ;  I don't use Boost. Yes, I know, I'm a heretic and all that. I don't really want to create an external dependency as I myself hate tutorials and samples (and libraries, for that matter) that list a whole bunch of things I need to have pre-installed. I really like unzip-and-run type of solutions (this means binaries should be included as well); besides, Boost is a bit too massive for my comfort and threading is the only thing I would use it for. I'll read up on the OpenMP compiler extensions, though!Thanks for your replies, guys!   ;Quote:Original post by ComicSansMSA light-weight alternative would be the use of the OpenMP compiler extensions. Those work quite well for simple parallelization tasks and are supported by most of the mainstream compilers today.Let me refine this to "lightweight in use, but not lightweight under the hood". The gnu implementation actually uses pthreads.   ;Quote:Original post by irreversibleI don't really want to create an external dependency as I myself hate tutorials and samples (and libraries, for that matter) that list a whole bunch of things I need to have pre-installed.You're going to have to include *something* though, right? And you wouldn't need to include all of boost, just the threads stuff (and maybe some of the system/config headers).Quote:I really like unzip-and-run type of solutions (this means binaries should be included as well)Is this not in conflict with your desire to have a cross-platform distribution?The reality is that creating cross platform distributions is hard and fiddly. Most of the leading Linux distributions have somewhat incompatible package management systems, Mac OS X has about 3 for OSS and Windows doesn't have one at all, as far as I'm aware.If you're unable to test your code on different platforms, then just make sure you've abstracted-away all of the platform-specific stuff behind interfaces that people can implement for other platforms ('people' might be you in future).   ;  pthread can be linked statically using the -static flag. On windows use pthreadswin32 which can be made into a static library.Quote:The Win32 pthreads is normally implemented as a dynamic link library (DLL). This has some notable advantages from the Win32 point of view, but it also more closely models existing pthread libraries on UNIX which are usually shared objects (e.g. libpthread.so). Please note though, that the library  can also be built for static linking if necessary.;  "Boost is a bit too massive for my comfort"Boost is designed exactly so you can pick and choose which parts you use. It's entirely possible to use boost::threads and ignore all the rest of it.On linux (for example) the different parts of boost are actually different packages and you can choose to only install a subset of them (although generally people will do all of them).Threads is different from most boost components in that it has a library (rather than just being headers). You can, however, build just the threads part and statically link that.;  "Most of the leading Linux distributions have somewhat incompatible package management"It is *just about* possible to write a single installer tool which will work across a wide range of distributions. One can then just "alien" the DEB package into an RPM or whatever.It's decidedly non-trivial however.;Quote:Original post by Katie"Most of the leading Linux distributions have somewhat incompatible package management"It is *just about* possible to write a single installer tool which will work across a wide range of distributions. One can then just "alien" the DEB package into an RPM or whatever.It's decidedly non-trivial however.Let me add that you can still work around package management and install into /home/you or somewhere. Though this is considered bad practice as it circumvents all the advantages of a central package management.   