Difference pthreads.library/threads.library and -athread=native (extended)

@all

See topic...

I have
pthreads.library 53.12 (24.05.2020)
from, i think, the latest SDK?
53.11 at least, and an update from somewhere...

and
threads.library 26700 ----rwed 31-May-05 14:42:10
probably v1.4 from Os4Depot.net (http://www.os4depot.net/?function=sho ... library/misc/pthreads.lha)

Do i really need the two?
Is the latter one outdated since?
Why is the latter one called pthreads.library, but threads.library in the package?
Since the SDK provides also the latest includes, should threads.library be even around in the system anymore? (Mix of libraries can lead to hard to track crashes)

Thank you

@Raziel

Since noone else answers this, I'll give it a go. It most Likely started out as threads.library perhaps changes were made which made it even more posix like so to make it more relevant to people they changed the name to pthreads for posix threads... you can check if the headers are similar and the final test is to move the current threads.library to for instance sys:storage and do a soft link from pthreads.library to threads.library and try to run with something that demands threads.library

@beanbandit

Thank you
I've since renamed threads.library so it won't get picked up in any way and I haven't gotten any bad feedback from the programs.
SDK includes have been updated as well and are not using threads.library, as far as I can see...so I guess it's safe to say the os4depot version is obsolete

threads.library is part of an early port of pthreads.

It had issues and was discontinued in favour of pthreads.library, which was rewritten from scratch

However, some software that uses pthreads and hasn't been rebuilt againast the newer version might require threads.library

One example is perl 5.8 (but not later versions) which you might possibly have installed in paralelle with later version of perl if you like playing "Frozen".

It's completely safe to have both threads.library and pthreads.library installed at the same time. (they have different names and won't get confused).

@beanbandit

Quote:

Nice try But threads was always a port of the pthreads API. It's author Thomas Frieden I think, decided to abandon it and replace it with new port reworked from scratch.

Quote:

Yikes! Don't even think about doing that, libraries have different names for good reason! They are not compatable in anyway. Actually ramlib expects the libraries name and filename to match so it might not even load, but if it did it would crash 100%!

@broadblues

Ah, thank you
Well, i deleted it since, if some program starts to complain i know where to look

@all

Extending my original question to -athread=native in compilations.

Are they different or just different approaches to the same goal?

If, for example, i wanted to use the native athreads over pthreads, would that work, or would i have to use pthreads in any way if a program relies on it?

libcurl f.e.
It's the only dependancy that includes pthreads.
What if i instead use -athread=native exclusively and drop pthreads?
Is that possible or will libcurl always rely on it except theres a new version of libcurl compiled without pthreads? (If that is even possible)?

I'm asking because it's a large build and i don't want to waste time only to be stopped after two hours when it won't work.

Thank you

@Raziel

Not really sure what athreads are?

There's no particuar reason not use pthreads of a projects you are using depends on them. It will much simpler than trying to create your own threading system using CreateNewProc() and friends.

@Raziel

-athread switch is to choose the threading model for C++11 concurrency features. If your C++ project is NOT using std::thread and friends, then stick to -athread=single (binary should be smaller). If you need C++11 concurrency features, then you should use -athread=native.

If your project is otherwise depending on pthreads, this switch doesn't change that.

@Capehill
@broadblues

Got it, thank you