Conference turris::digital_unix

    Can anyone elaborate on these questions, any help appreciated.
    
    Questions regarding Digital UNIX 3.2g threads:
    
    1. Are all of the system and function calls defined in
    /usr/lib/libc_r.a
    thread-safe?
    
    
    2. How can I tell which of the POSIX functions defined in
    /usr/ccs/lib/librt.a are thread-safe? (I have noticed that some of the
    POSIX-defined system calls are defined in libc_r.a, while others,
    especially those that are new API's not previously part of UNIX, are
    not
    found in libc_r.a, but in librt.a)  In particular, I'm interested in
    those librt.a system calls derived from psx4_ipc.o, such as the
    mq_* family of system calls like mq_open, mq_send, and mq_receive.
    However, I'm interested in obtaining a more comprehensive list for
    future reference.
    
    3. When I upgrade to version 4.0 will any of these answers be changing?
    
    Douglas Klimas
    MCI Mission Critical Support
    

    
    
    
    Hi, Douglas,
    
    1. I think so -> (Someone correct me if I'm wrong on this one!) ;-)
    
    2. All of the POSIX 1003.1b message queue routines are thread safe.
    
    3. No.
    
    Best Regards,
    
    Lee Parker                       [email protected]
    Digital UNIX Device Driver & Realtime Support
    Realtime Expertise Center        1-800-354-9000
    

>>   1. Are all of the system and function calls defined in 
>>      /usr/lib/libc_r.a thread-safe?
>    1. I think so -> (Someone correct me if I'm wrong on this one!) ;-)

I believe there may have been a few obscure bugs in libc_r, but in general,
anything in there should be considered "thread safe".

>>   2. How can I tell which of the POSIX functions defined in
>>      /usr/ccs/lib/librt.a are thread-safe?
>    2. All of the POSIX 1003.1b message queue routines are thread safe.

All of librt is thread-safe.

>>   3. When I upgrade to version 4.0 will any of these answers be changing?
>    3. No.

Actually, Lee's answer is correct (sort of), but also completely wrong. The
main reason he's wrong is that there IS no libc_r in 4.0 -- so "everything
changes". On the other hand, he's right because libc_r is replaced by a fully
thread-safe libc, and some additional libraries have become thread-safe, but
no previously thread-safe libraries have become "unsafe".

	/dave

    
    
    
    	
    >> main reason he's wrong is that there IS no libc_r in 4.0
    
    Um, Dave, I know what you mean, but there IS a libc_r on 4.0:
    
    -rw-r--r--   2 bin      bin      1578192 Nov 15 21:09 /shlib/libc.so
    -rw-r--r--   2 bin      bin      1578192 Nov 15 21:09 /shlib/libc_r.so
    
    it's just a hard link to libc.so now! :-)
    
    Thanks for clarifying my reply!
    
    Also, I have been through this issue with MCI before - if they think
    there is a problem w/ message queue's and thread-safeness, then please
    have them give us a reproducer to show the problem. They would/could
    not do that last time I asked. Be aware that on 4.0, POSIX message queue's
    are broken. They are ok on 4.0A/B - if you need a patch, let me know.
    
    Lee
    
    

>    Um, Dave, I know what you mean, but there IS a libc_r on 4.0:
>
>    -rw-r--r--   2 bin      bin      1578192 Nov 15 21:09 /shlib/libc.so
>    -rw-r--r--   2 bin      bin      1578192 Nov 15 21:09 /shlib/libc_r.so
>
>    it's just a hard link to libc.so now! :-)

I can take humorous petty literalism as well as anyone (better than some),
but I'm afraid this may confuse some people, so I'm going to correct you
instead of just grinning and hitting "next"...

There is no libc_r library on 4.0. There is a "libc_r" NAME (exclusively to
support old binaries that linked against it), which is nothing but an alias
to libc. This is a VERY important distinction, because the symbol preemption
required by the pre-4.0 libc_r "solution" cause all sorts of nasty problems.
In 4.0, there's just libc. It's thread-safe. It adapts to running without the
thread library in order to minimize the cost of thread-safety for nonthreaded
code. (Partially, it uses TIS for this, but since TIS is part of libc, it can
also go a little further in some places.)

What Dave didn't mention is that the loader will regard libc_r.so and libc.so
as being the -same- -file-, so when it gets the request to load "libc.so"
after it has already loaded "libc_r.so" it will skip the load.  Thus, there
is no "libc_r.so" -- there is only "libc.so" -- because any attempt to
reference "libc_r.so" will result in libc.so being loaded.

All of this is nearly moot anyway, because as of V4.0 no one should be
linking against libc_r.so anymore.


				Webb