🚀 go-pugleaf

In <1992Dec17.094108.12612@eua.ericsson.se> etxabju@eua.ericsson.se (Anders Bjurman) writes:

>In article 26031@cs.tu-berlin.de, ernst@opal.cs.tu-berlin.de (Ernst Kloecker) writes:
>>Hi,
>>
>>what precautions do I have to take when calling C-library functions from
>>different threads in one process ?

>There are (at least) two versions of the library - one "normal" and one thread safe.
>In MSC you invoke the thread safe library with -MT.

In C Set/2, you use the -Gm+ switch.

>>What happens to static variables like 'errno' ?

>No problem. errno is redefined with the preprocessor to a thread-safe function:
>#define errno thread_safe_errno_function() or something like that.

Same with C Set/2.

>>Can I safely call '...printf()' from different threads ?

>Not quite sure, but I think so. printf/sprintf etc uses (in MSC) a static result
>array. This array is guarded with semaphores. However, there can be a small risk
>that the output from several threads are mixed with each other (but only one
>of them calls printf() of course).

Yes, you can safely call any runtime function from separate threads, as long
as you link with the proper library (or let the compiler generate the "default
library object records" so that the linker knows).

>>Or are the only safe functions the OS-functions in 'bsedos.h' ?

>Sorry.

All of the OS/2 API are thread safe; it would be stupid for them not to be
since this is, after all, a multi-threading OS.

>>Or are even those functions not completely thread-safe ?
>>
>Not absolutly sure how they are implemented, but functions like strtok(),
>localtime(), gmtime() etc seems a bit dangerous - I guard them with a semaphore
>when I use them.

I think he was referring to the system API.  Again, both the C Set/2 and
system API are thread-safe.

Cheers,
Q
-- 
"If you choose not to decide, you  | "My other body is in the shop" - seen
 still have made a choice" - Rush  |  on a T-shirt
------------------------------------------------------------------------