Menu
▾
▴
mingw-users
|
From: John P. <joh...@o2...> - 2014-04-07 10:59:56
|
Hello, Have been using Mingw recently to restore my 'C' skills on a PC rather than the microcontrollers I usually code for. (My PC is XP Professional) I want to add threads to my application and would appreciate suggestions as to apprepriate thread library(s) to use. Does one come with the normal Mingw distro? Is there a library/API that runs with Windows, xNIX and or Mac OS X? It would be nice to think that the same code could run on all three major OSs. Any help appreciated, Regards, John |
|
From: Kyle K. <rem...@gm...> - 2014-04-07 12:33:35
|
If C++ is possible for you, definitely look at Boost.Thread. Boost.Thread with ASIO is some pretty powerful stuff. For C, OpenMP is what you want. |
|
From: Eli Z. <el...@gn...> - 2014-04-07 15:57:07
|
> Date: Mon, 07 Apr 2014 11:59:42 +0100 > From: John Pote <joh...@o2...> > > I want to add threads to my application and would appreciate suggestions > as to apprepriate thread library(s) to use. Does one come with the > normal Mingw distro? Is there a library/API that runs with Windows, xNIX > and or Mac OS X? It would be nice to think that the same code could run > on all three major OSs. Windows provides its own native thread APIs, so you could use them. |
|
From: Keith M. <kei...@us...> - 2014-04-07 18:47:58
|
On 07/04/14 16:56, Eli Zaretskii wrote: >> Date: Mon, 07 Apr 2014 11:59:42 +0100 >> From: John Pote <joh...@o2...> >> >> I want to add threads to my application and would appreciate suggestions >> as to apprepriate thread library(s) to use. Does one come with the >> normal Mingw distro? Is there a library/API that runs with Windows, xNIX >> and or Mac OS X? It would be nice to think that the same code could run >> on all three major OSs. > > Windows provides its own native thread APIs, so you could use them. If I were writing for MS-Windows only, or if I were willing to write the code differently for individual platforms, then that would be my choice too. However, since the OP has expressed a preference for code which may be expected to compile, unchanged, for disparate platforms, pthreads may be a more attractive choice -- since GCC itself demands pthreads support, for multi-processor aware (libgomp) applications, we do provide, of necessity, a pthreads implementation for use with MinGW, as an alternative to native Windows threads. Another responder has suggested Boost threads (for C++); that's certainly an option which may be worthy of consideration, but it's an option which we do not directly support here, so you would need to seek further advice elsewhere. This same responder also suggested OpenMP, (for C, although it may be equally suitable for C++); AFAIK, that's just another way of saying "pthreads", (because libgomp is GCC's implementation of OpenMP, and libgomp uses pthreads). -- Regards, Keith. |
|
From: Eli Z. <el...@gn...> - 2014-04-07 19:47:45
|
> Date: Mon, 07 Apr 2014 19:47:49 +0100 > From: Keith Marshall <kei...@us...> > > On 07/04/14 16:56, Eli Zaretskii wrote: > >> Date: Mon, 07 Apr 2014 11:59:42 +0100 > >> From: John Pote <joh...@o2...> > >> > >> I want to add threads to my application and would appreciate suggestions > >> as to apprepriate thread library(s) to use. Does one come with the > >> normal Mingw distro? Is there a library/API that runs with Windows, xNIX > >> and or Mac OS X? It would be nice to think that the same code could run > >> on all three major OSs. > > > > Windows provides its own native thread APIs, so you could use them. > > If I were writing for MS-Windows only, or if I were willing to write the > code differently for individual platforms, then that would be my choice > too. However, since the OP has expressed a preference for code which > may be expected to compile, unchanged, for disparate platforms, pthreads > may be a more attractive choice -- since GCC itself demands pthreads > support, for multi-processor aware (libgomp) applications, we do > provide, of necessity, a pthreads implementation for use with MinGW, as > an alternative to native Windows threads. Suit yourself, but I find pthreads to have "issues". E.g., Guile compiled with pthreads hangs when it tries to start one more thread. So my advice is still to go native, it's not like hiding Windows thread APIs behind some wrappers is hard. Portable APIs are great when the ports are dependable; unfortunately IME pthreads are not. |
|
From: Eli Z. <el...@gn...> - 2014-04-08 17:41:52
|
> Date: Mon, 7 Apr 2014 17:33:42 -0400 > From: "K. Frank" <kfr...@gm...> > > > Suit yourself, but I find pthreads to have "issues". E.g., Guile > > compiled with pthreads hangs when it tries to start one more thread. > > So my advice is still to go native, it's not like hiding Windows > > thread APIs behind some wrappers is hard. Portable APIs are great > > when the ports are dependable; unfortunately IME pthreads are not. > > I would be curious to know which windows port of pthreads (and which > version) you have had trouble with. I used pthreads-w32 provided by the MinGW site (of course). At the time (June 2013), the latest version there was pthreads-w32-2.9.0-pre-20110507-2. I see that now there's a newer version, pthreads-w32-2.9.1. But I don't think the version matters here: a couple of weeks ago someone reported on the Guile list that he tried to build the latest Guile with MinGW, I'm sure with the latest pthreads-w32, and hit the same problem. > >From recollection, mingw (at least an older version) provided a copy > of pthreads-win32. Is this the port you found buggy, and is the bug > you see a known issue? Indeed, see above. |
|
From: Eli Z. <el...@gn...> - 2014-04-08 17:48:01
|
> Date: Tue, 08 Apr 2014 00:43:05 +0100 > From: Keith Marshall <kei...@us...> > > > I would be curious to know which windows port of pthreads (and which > > version) you have had trouble with. > > As would I. See my other message in this thread. I don't think this is a bug in some particular version of pthreads-w32, though. > While I do favour the native API for my own work, I'm not aware of > any complaints having been made previously, about the pthreads > implementation which we offer, (and which is required for our > GCC-4.x to support libgomp, and so provide multi-processor support. I debugged the problem quite a lot and published the details. You should be able to find that in the archives of the Guile mailing list. No one on the Guile list was able to suggest any ideas as to why the hang could happen. For all I know, this could be a problem specific to how Guile uses pthreads. But note that the same code works flawlessly on GNU/Linux, so -- and this is the important part for me -- pthreads is not really a 100% reliable portable library, at least in this important use case. Note that, when configured without threads, Guile compiles with MinGW and works without any problems whatsoever. |
|
From: K. F. <kfr...@gm...> - 2014-04-07 21:33:49
|
Hello Eli! On Mon, Apr 7, 2014 at 3:47 PM, Eli Zaretskii <el...@gn...> wrote: >> Date: Mon, 07 Apr 2014 19:47:49 +0100 >> From: Keith Marshall <kei...@us...> >> >> On 07/04/14 16:56, Eli Zaretskii wrote: >> >> Date: Mon, 07 Apr 2014 11:59:42 +0100 >> >> From: John Pote <joh...@o2...> >> >> >> >> I want to add threads to my application and would appreciate suggestions >> >> as to apprepriate thread library(s) to use. >> >> ... >> > Windows provides its own native thread APIs, so you could use them. >> ... >> we do >> provide, of necessity, a pthreads implementation for use with MinGW, as >> an alternative to native Windows threads. > > Suit yourself, but I find pthreads to have "issues". E.g., Guile > compiled with pthreads hangs when it tries to start one more thread. > So my advice is still to go native, it's not like hiding Windows > thread APIs behind some wrappers is hard. Portable APIs are great > when the ports are dependable; unfortunately IME pthreads are not. I would be curious to know which windows port of pthreads (and which version) you have had trouble with. >From recollection, mingw (at least an older version) provided a copy of pthreads-win32. Is this the port you found buggy, and is the bug you see a known issue? Thanks for any info about this. K. Frank |
|
From: Keith M. <kei...@us...> - 2014-04-07 23:43:15
|
On 07/04/14 22:33, K. Frank wrote: > On Mon, Apr 7, 2014 at 3:47 PM, Eli Zaretskii wrote: >>> Date: Mon, 07 Apr 2014 19:47:49 +0100 >>> From: Keith Marshall >>> >>> On 07/04/14 16:56, Eli Zaretskii wrote: >>>>> Date: Mon, 07 Apr 2014 11:59:42 +0100 >>>>> From: John Pote >>>>> >>>>> I want to add threads to my application and would appreciate suggestions >>>>> as to apprepriate thread library(s) to use. >>>>> ... >>>> Windows provides its own native thread APIs, so you could use them. >>> ... >>> we do >>> provide, of necessity, a pthreads implementation for use with MinGW, as >>> an alternative to native Windows threads. >> >> Suit yourself, but I find pthreads to have "issues". E.g., Guile >> compiled with pthreads hangs when it tries to start one more thread. >> So my advice is still to go native, ... It's not a matter of suiting myself; I do tend to favour the native APIs, for my own applications. I was merely pointing out that pthreads may be a better fit, given the OPs stated preference for a consistent cross platform API. Of course, if the OP does choose this option, he should take note of various limitations, and feature omissions, as noted in the pthreads-w32 source distribution. >> ... it's not like hiding Windows thread APIs behind some wrappers >> is hard. Portable APIs are great when the ports are dependable; >> unfortunately IME pthreads are not. > > I would be curious to know which windows port of pthreads (and which > version) you have had trouble with. As would I. While I do favour the native API for my own work, I'm not aware of any complaints having been made previously, about the pthreads implementation which we offer, (and which is required for our GCC-4.x to support libgomp, and so provide multi-processor support. > From recollection, mingw (at least an older version) provided a copy > of pthreads-win32. Yes, this is the case. It is today, and AFAIK always has been, an unmodified copy from https://www.sourceware.org/pthreads-win32/, (with their 2.9.1 release being our current offering). -- Regards, Keith. |
|
From: Matt D. <ma...@gm...> - 2014-04-08 21:38:48
|
On 4/7/2014 12:59, John Pote wrote: > Hello, > Have been using Mingw recently to restore my 'C' skills on a PC rather > than the microcontrollers I usually code for. (My PC is XP Professional) > > I want to add threads to my application and would appreciate suggestions > as to apprepriate thread library(s) to use. Does one come with the > normal Mingw distro? Is there a library/API that runs with Windows, xNIX > and or Mac OS X? It would be nice to think that the same code could run > on all three major OSs. Hi! If you can use C++ (quite likely for a PC target), then `<thread>` header is the standard (and thus cross-platform): http://en.cppreference.com/w/cpp/thread And, possibly more importantly, the `<future>` header -- in particular, `std::async` is often a better tool for the job (like executing a function in the background) than emulating the same functionality manually via thread/create/join: http://en.cppreference.com/w/cpp/thread/async I would also add a very strong recommendation _AGAINST_ using non-standard, platform-specific C-style APIs like PThreads in this context -- these will not interoperate with standard C++ constructs (like lambdas) seamlessly and will lose type-safety compared to standard multithreading facilities (e.g., std::thread preserves types of function arguments, while using pthreads requires you to drop to the lowest-common-denominator (read: completely opt-out of the type system) by using generic pointer / `void*`). These platform-specific APIs are also (naturally) non-portable: note that POSIX is just one platform among many, and limiting yourself to it is hardly better than limiting yourself to, say, MFC/Win32 (which I wouldn't recommend, either). In the end, it's bad practice that unnecessarily limits the portability of your code and forces a dependency (upon you and your potential users) on toolchains that happen to support it. // Naturally, PThreads are out of the running anyway, since you've specified a requirement of "a library/API that runs with Windows, xNIX and or Mac OS X?". PThreads do not fulfill this requirement. If you're stuck with an ancient compiler that still doesn't respect the standard, you can also use Boost.Thread, which is a practically a drop-in replacement: http://www.boost.org/libs/thread That being said, there is a risk that a compiler with such a poor level of standard support may also be buggy and/or unreliable in other ways (IME, lack of updates and unpatched bugs often go together, of course one can always gamble that "this time it's different") -- hence, I'd perhaps consider not using such a compiler. Given that you're using a PC, you have a wide variety of toolchains to choose from :-) -- hence, there is absolutely no reason to limit yourself to sub-optimal/non-standard/non-portable choices and suffer the consequences. // Similarly, the latest C standard also supports multithreading, see header |`<threads.h>|`: http://en.cppreference.com/w/c/thread // Note, however, that the C standard makes this support optional (can check via the ` __STDC_NO_THREADS__` macro). Best regards, Matt > > Any help appreciated, > Regards, > John > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees_APR > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
|
From: John P. <joh...@o2...> - 2014-04-11 11:02:40
|
Thanks everyone for the replies. Sadly I've never gone down the C++ route so that's not an option for me. It would be interesting to know how compatible the C++ 'standard' libraries mentioned are across OSs and compilers, how much of a common denominator they impliment compared to the raw OSs APIs. Write once run everywhere may be a bit of a pipe dream. I've found that the GCC docs about sockets are somewhat different to the Winsock docs. API seems to be the same (as far as I've used it) but the error messages and how you get them quite different. And since handling errors can be a large and crucial part of an app..... pthreads seems to be the way to go for the moment. I've just bought myself a Raspbarry PI to get some ARM/Linux experience so hopefully the API at least will cross over to the Raspberry pi in principle if not in all the details. Thanks again, John On 08/04/2014 22:38, Matt D. wrote: > On 4/7/2014 12:59, John Pote wrote: >> Hello, >> Have been using Mingw recently to restore my 'C' skills on a PC rather >> than the microcontrollers I usually code for. (My PC is XP Professional) >> >> I want to add threads to my application and would appreciate suggestions >> as to apprepriate thread library(s) to use. Does one come with the >> normal Mingw distro? Is there a library/API that runs with Windows, xNIX >> and or Mac OS X? It would be nice to think that the same code could run >> on all three major OSs. > Hi! > > If you can use C++ (quite likely for a PC target), then `<thread>` > header is the standard (and thus cross-platform): > http://en.cppreference.com/w/cpp/thread > And, possibly more importantly, the `<future>` header -- in > particular, `std::async` is often a better tool for the job (like > executing a function in the background) than emulating the same > functionality manually via thread/create/join: > http://en.cppreference.com/w/cpp/thread/async > > I would also add a very strong recommendation _AGAINST_ using > non-standard, platform-specific C-style APIs like PThreads in this > context -- these will not interoperate with standard C++ constructs > (like lambdas) seamlessly and will lose type-safety compared to > standard multithreading facilities (e.g., std::thread preserves types > of function arguments, while using pthreads requires you to drop to > the lowest-common-denominator (read: completely opt-out of the type > system) by using generic pointer / `void*`). > > These platform-specific APIs are also (naturally) non-portable: note > that POSIX is just one platform among many, and limiting yourself to > it is hardly better than limiting yourself to, say, MFC/Win32 (which I > wouldn't recommend, either). In the end, it's bad practice that > unnecessarily limits the portability of your code and forces a > dependency (upon you and your potential users) on toolchains that > happen to support it. > > // Naturally, PThreads are out of the running anyway, since you've > specified a requirement of "a library/API that runs with Windows, xNIX > and or Mac OS X?". PThreads do not fulfill this requirement. > > If you're stuck with an ancient compiler that still doesn't respect > the standard, you can also use Boost.Thread, which is a practically a > drop-in replacement: > http://www.boost.org/libs/thread > That being said, there is a risk that a compiler with such a poor > level of standard support may also be buggy and/or unreliable in other > ways (IME, lack of updates and unpatched bugs often go together, of > course one can always gamble that "this time it's different") -- > hence, I'd perhaps consider not using such a compiler. Given that > you're using a PC, you have a wide variety of toolchains to choose > from :-) -- hence, there is absolutely no reason to limit yourself to > sub-optimal/non-standard/non-portable choices and suffer the consequences. > > // Similarly, the latest C standard also supports multithreading, see > header |`<threads.h>|`: http://en.cppreference.com/w/c/thread > // Note, however, that the C standard makes this support optional (can > check via the ` __STDC_NO_THREADS__` macro). > > Best regards, > > Matt > > > >> Any help appreciated, >> Regards, >> John >> >> ------------------------------------------------------------------------------ >> Put Bad Developers to Shame >> Dominate Development with Jenkins Continuous Integration >> Continuously Automate Build, Test & Deployment >> Start a new project now. Try Jenkins in the cloud. >> http://p.sf.net/sfu/13600_Cloudbees_APR >> _______________________________________________ >> MinGW-users mailing list >> Min...@li... >> >> This list observes the Etiquette found at >> http://www.mingw.org/Mailing_Lists. >> We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. >> >> _______________________________________________ >> You may change your MinGW Account Options or unsubscribe at: >> https://lists.sourceforge.net/lists/listinfo/mingw-users >> Also:mailto:min...@li...?subject=unsubscribe |
|
From: K. F. <kfr...@gm...> - 2014-04-11 13:11:43
|
Hello John! On Fri, Apr 11, 2014 at 7:02 AM, John Pote <joh...@o2...> wrote: > Thanks everyone for the replies. Sadly I've never gone down the C++ route so > that's not an option for me. It would be interesting to know how compatible > the C++ 'standard' libraries mentioned are across OSs and compilers, how > much of a common denominator they impliment compared to the raw OSs APIs. std::thread (and friends) are truly part of the C++ standard (as of C++11). If you write standards-compliant code (e.g., no platform-specific extensions or undefined behavior), then your code will be (by definition) portable across standards-compliant implementations. By now I think that many std::thread implementations are quite good, so you can expect to get very good compatibility across platforms. > Write once run everywhere may be a bit of a pipe dream. I've found that the > GCC docs about sockets are somewhat different to the Winsock docs. But sockets are not part of the C++ standard. Posix sockets and winsock are admittedly different (although similar), so one has no expectation of sockets code being cross-platform (and no language standard suggests that it should be). > ... > pthreads seems to be the way to go for the moment. Because you wish to stick with C, then pthreads will be your (most nearly) cross-platform approach. (If you were to use C++ then, as others have recommended, std::thread would be the best choice.) Note that pthreads is part of posix, and is a standard. But it's an api standard, and not part of any language standard (i.e., not part of the C or C++ standard). But linux and most (all?) versions of unix support pthreads, as do third-party libraries on windows. Be aware of one minor issue: As I understand it, in pthreads (i.e., the posix standard), pthread_t (e.g., the thing returned by pthread_self()) is supposed to be an opaque handle to a thread. But in linux and probably all unix implementations, pthread_t is an integral type, and (as I understand it) a lot of existing code that uses pthreads relies on pthread_t being an integral type. The pthreads library shipped with mingw (pthreads-win32) implements pthread_t as a struct, and will therefore break some of the pthreads code found in the wild (code that is presumably not compliant with the posix pthreads standard). This should not be a problem with your own code if you don't assume that pthread_t is integral, but it could be a problem if you use a library or code fragments that you copy form here or there. I believe that winpthreads, the pthreads library shipped with mingw-w64 (Note that mingw-w64 is a separate project with a separate mailing list.) does implement pthread_t as an integral type, and I believe this was one of the motivations for developing winpthreads as an alternative to pthreads-win32. > I've just bought myself a > Raspbarry PI to get some ARM/Linux experience so hopefully the API at least > will cross over to the Raspberry pi in principle if not in all the details. > > Thanks again, > John Happy Multi-Threaded Hacking! K. Frank |
|
From: John P. <joh...@o2...> - 2014-04-11 23:50:58
|
Thanks for the feedback and tips, most useful. My lack of C++ is proving a general problem these days as so many embedded projects have used it. Perhaps I should learn it. Anyway annotations below, On 11/04/2014 14:11, K. Frank wrote: > Hello John! > > On Fri, Apr 11, 2014 at 7:02 AM, John Pote <joh...@o2...> wrote: >> Thanks everyone for the replies. Sadly I've never gone down the C++ route so >> that's not an option for me. It would be interesting to know how compatible >> the C++ 'standard' libraries mentioned are across OSs and compilers, how >> much of a common denominator they impliment compared to the raw OSs APIs. > std::thread (and friends) are truly part of the C++ standard (as of C++11). > If you write standards-compliant code (e.g., no platform-specific extensions > or undefined behavior), then your code will be (by definition) portable across > standards-compliant implementations. By now I think that many std::thread > implementations are quite good, so you can expect to get very good > compatibility across platforms. Quit good or actually compliant? But if the semantics of the underlying OS are different even a fully compliant compiler will produce code that in some cases will behave differently on different OSs. I'm thinking particularly of error conditions and their causes. It always seems to me that the mark of a good application is how it handles fault conditions. How I used to hate Windozes throwing up the uninformative message box "missing dll". And for many apps much if not the majority of the code is good (ie helpfull -- why did the problem occur) error handling. > >> Write once run everywhere may be a bit of a pipe dream. I've found that the >> GCC docs about sockets are somewhat different to the Winsock docs. > But sockets are not part of the C++ standard. Posix sockets and winsock > are admittedly different (although similar), so one has no expectation of > sockets code being cross-platform (and no language standard suggests > that it should be). > >> ... >> pthreads seems to be the way to go for the moment. > Because you wish to stick with C, then pthreads will be your (most nearly) > cross-platform approach. (If you were to use C++ then, as others have > recommended, std::thread would be the best choice.) > > Note that pthreads is part of posix, and is a standard. But it's an api > standard, and not part of any language standard (i.e., not part of the > C or C++ standard). But linux and most (all?) versions of unix support > pthreads, as do third-party libraries on windows. Isn't this an advantage? Any language can then be compliant with the common OS standard. > > Be aware of one minor issue: As I understand it, in pthreads (i.e., the > posix standard), pthread_t (e.g., the thing returned by pthread_self()) is > supposed to be an opaque handle to a thread. But in linux and probably > all unix implementations, pthread_t is an integral type, and (as I understand > it) a lot of existing code that uses pthreads relies on pthread_t being an > integral type. If pthread_t is implimentation dependant, and isn't that the point of using a typedef, then it is intended for passing info between the library functions and should not be fiddled with. Assumptions, as my old supervisor used to say, are dangerous things. > > The pthreads library shipped with mingw (pthreads-win32) implements > pthread_t as a struct, and will therefore break some of the pthreads > code found in the wild (code that is presumably not compliant with the > posix pthreads standard). I used your ming-get version 0.6.2-beta-20131004-1 to install mingw but could not find any pthreads files anywhere. Have downloaded them from http://www.sourceware.org/pthreads-win32/. > > This should not be a problem with your own code if you don't assume > that pthread_t is integral, but it could be a problem if you use a library > or code fragments that you copy form here or there. > > I believe that winpthreads, the pthreads library shipped with mingw-w64 > (Note that mingw-w64 is a separate project with a separate mailing list.) > does implement pthread_t as an integral type, and I believe this was one > of the motivations for developing winpthreads as an alternative to > pthreads-win32. Thanks for the tip, money's tight at the monent so I'll stick with my old win32 desktop. > >> I've just bought myself a >> Raspbarry PI to get some ARM/Linux experience so hopefully the API at least >> will cross over to the Raspberry pi in principle if not in all the details. >> >> Thanks again, >> John > > Happy Multi-Threaded Hacking! > > > K. Frank > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4355 / Virus Database: 3882/7330 - Release Date: 04/11/14 > > |
|
From: Emanuel F. <E.F...@op...> - 2014-04-11 23:52:32
|
Hello, Just trying to contribute a piece of experience: we've been using pthreads in Mingw since ages, both in 32 and 64 bits, and it works extremely well for us (and we're in some rather serious multi-threaded algorithms). I am extremely surprised a previous post mentioned "glitches". All the best, Emanuel On 11-Apr-14 15:11, K. Frank wrote: > Hello John! > > On Fri, Apr 11, 2014 at 7:02 AM, John Pote <joh...@o2...> wrote: >> Thanks everyone for the replies. Sadly I've never gone down the C++ route so >> that's not an option for me. It would be interesting to know how compatible >> the C++ 'standard' libraries mentioned are across OSs and compilers, how >> much of a common denominator they impliment compared to the raw OSs APIs. > std::thread (and friends) are truly part of the C++ standard (as of C++11). > If you write standards-compliant code (e.g., no platform-specific extensions > or undefined behavior), then your code will be (by definition) portable across > standards-compliant implementations. By now I think that many std::thread > implementations are quite good, so you can expect to get very good > compatibility across platforms. > >> Write once run everywhere may be a bit of a pipe dream. I've found that the >> GCC docs about sockets are somewhat different to the Winsock docs. > But sockets are not part of the C++ standard. Posix sockets and winsock > are admittedly different (although similar), so one has no expectation of > sockets code being cross-platform (and no language standard suggests > that it should be). > >> ... >> pthreads seems to be the way to go for the moment. > Because you wish to stick with C, then pthreads will be your (most nearly) > cross-platform approach. (If you were to use C++ then, as others have > recommended, std::thread would be the best choice.) > > Note that pthreads is part of posix, and is a standard. But it's an api > standard, and not part of any language standard (i.e., not part of the > C or C++ standard). But linux and most (all?) versions of unix support > pthreads, as do third-party libraries on windows. > > Be aware of one minor issue: As I understand it, in pthreads (i.e., the > posix standard), pthread_t (e.g., the thing returned by pthread_self()) is > supposed to be an opaque handle to a thread. But in linux and probably > all unix implementations, pthread_t is an integral type, and (as I understand > it) a lot of existing code that uses pthreads relies on pthread_t being an > integral type. > > The pthreads library shipped with mingw (pthreads-win32) implements > pthread_t as a struct, and will therefore break some of the pthreads > code found in the wild (code that is presumably not compliant with the > posix pthreads standard). > > This should not be a problem with your own code if you don't assume > that pthread_t is integral, but it could be a problem if you use a library > or code fragments that you copy form here or there. > > I believe that winpthreads, the pthreads library shipped with mingw-w64 > (Note that mingw-w64 is a separate project with a separate mailing list.) > does implement pthread_t as an integral type, and I believe this was one > of the motivations for developing winpthreads as an alternative to > pthreads-win32. > >> I've just bought myself a >> Raspbarry PI to get some ARM/Linux experience so hopefully the API at least >> will cross over to the Raspberry pi in principle if not in all the details. >> >> Thanks again, >> John > > Happy Multi-Threaded Hacking! > > > K. Frank > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
