MT library in a non-MT program

MT library in a non-MT program

Post by Drazen Kac » Wed, 13 Jun 2001 19:22:44



The whole thing is a bad juju, I suppose, but I'd like to know what would
happen. With the current implementation, at least.

Suppose I have a single-threaded program. At some point that program
dlopens a library which was compiled with -D_REENTRANT and is linked with
the thread library. In its normal course of operation the library wants to
create several threads which would perform whatever the library is
supposed to do. Would this work?

Is there any difference if the library is a direct dependency of the
executable?

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |

 
 
 

MT library in a non-MT program

Post by Philip Bro » Thu, 14 Jun 2001 00:05:04



>The whole thing is a bad juju, I suppose, but I'd like to know what would
>happen. With the current implementation, at least.

>Suppose I have a single-threaded program. At some point that program
>dlopens a library which was compiled with -D_REENTRANT and is linked with
>the thread library. In its normal course of operation the library wants to
>create several threads which would perform whatever the library is
>supposed to do. Would this work?

Linking issues aside, threaded executables run just fine on single-cpu
boxes. So unless there's some unstated requirement for
"These two threads must run simultaneously or the whole thing locks up"
you should be fine.

Mind you, there may well be such a requirement. If its your own code, you
can sort of cheat by doing a thr_setconcurrency() to 2 or more.
This cheats by timeslicing the threads.
Otherwise, the system defaults to (concurrency level)==(number of CPUs),
which has a tendancy to run the thread consecutively , rather than
concurrently.

[last I heard, which was back in solaris 2.6 or 7 anyways]

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

 
 
 

MT library in a non-MT program

Post by Drazen Kac » Thu, 14 Jun 2001 01:42:19




> >Suppose I have a single-threaded program. At some point that program
> >dlopens a library which was compiled with -D_REENTRANT and is linked with
> >the thread library. In its normal course of operation the library wants to
> >create several threads which would perform whatever the library is
> >supposed to do. Would this work?

> Linking issues aside, threaded executables run just fine on single-cpu
> boxes. So unless there's some unstated requirement for
> "These two threads must run simultaneously or the whole thing locks up"
> you should be fine.

This should not be a problem.

Quote:> Otherwise, the system defaults to (concurrency level)==(number of CPUs),
> which has a tendancy to run the thread consecutively , rather than
> concurrently.

I had something else in mind. With the normal MT program the thread library is
mapped and initialized before libc. In the above dlopen() scenario, libc would be
initialized and used before the thread library initialization. I don't know if
there are possible problems with this reversal. And when the program calls dlclose
(eventually), the library would be unmapped, but the thread library would stay for
the entire lifetime of the program.

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |

 
 
 

MT library in a non-MT program

Post by Roger A. Faulkn » Fri, 15 Jun 2001 16:11:14




>The whole thing is a bad juju, I suppose, but I'd like to know what would
>happen. With the current implementation, at least.

>Suppose I have a single-threaded program. At some point that program
>dlopens a library which was compiled with -D_REENTRANT and is linked with
>the thread library. In its normal course of operation the library wants to
>create several threads which would perform whatever the library is
>supposed to do. Would this work?

Nothing particularly bad happens.
The process just suddenly becomes multithreaded,
with all the implications thereof.

Quote:>Is there any difference if the library is a direct dependency of the
>executable?

Yes.  In this case, the process is multithreaded from the
outset, just as though it was linked directly with -lthread.

Roger Faulkner

 
 
 

1. libqt3-mt vs. libqt3c102-mt on Debian

Hi all,

KDE is running on my Debian unstabel system, but I'm stuck with a package
conflict.  libqt3c102-mt (3:3.1.1-3) can't live with libqt3-mt
(2:3.1.1+cvs.20021220-1).  
The difference between the libqt3c102-mt and libqt3-mt versions is unclear
to me...  
I'm not sure whether I'm doing somthing wrong or I just have to wait untill
this conflict is solved by the package managers.

Google isn't very helpfull on this topic either.  Can anyone tell me what is
wrong?

Thanks

Pieter

2. 2 weird questions

3. mt question - "mt eom" doesn't work

4. redhat 6.2 or 7.0?

5. Query about MT Safe and MT Unsafe Stream Drivers

6. RedHat hard drive installation problem

7. Ftape and mt problems - mt-patch?

8. Plexus P-75 machines and SystemIV ver2

9. Solaris MT program, -D_REENTRANT and legacy libraries.

10. Side effects of _REENTRANT definition on non-MT apps

11. tool to detect use of non-MT-safe functions?

12. New MT library announce

13. LDAP library MT-Safe?