[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming.threads

stateful libraries need termination on thread termination, how?

Florian Große-Coosmann

7/23/2004 10:36:00 AM

Hi,

Regarding POSIX threads on Linux.

We are developing a shared library for an interpreter which wraps
another shared library with state informations for each thread.

Our wrapper needs to call a cleanup function on a per-thread basis.

For some reasons it is impossible to force the user of the interpreter
to inform our wrapper of an immediately following thread's death.

We played a little bit with library finalization handlers and cleanup
handlers of pthread_key_create, but we couldn't manage to get all four
situations running in that way, that each threads gets a finalizer
running on each event:

1) active termination by foreign reasons (e.g. some signal stuff)

2) active termination by pthread_exit

3) passive termination by leaving the thread routine

4) unlinking the library which isn't used any longer, but some threads
persist

Is there a standardized protocol which should be used to get something
running (a finalizer routine) when a library needs to be cleaned up
in a MT environment without managing a list of involved threads by
our own starting from in to fini?

Cheers, Florian
3 Answers

Joe Seigh

7/23/2004 2:12:00 PM

0



Florian Große-Coosmann wrote:
>
> Hi,
>
> Regarding POSIX threads on Linux.
>
> We are developing a shared library for an interpreter which wraps
> another shared library with state informations for each thread.
>
> Our wrapper needs to call a cleanup function on a per-thread basis.
>
....
>
> Is there a standardized protocol which should be used to get something
> running (a finalizer routine) when a library needs to be cleaned up
> in a MT environment without managing a list of involved threads by
> our own starting from in to fini?
>

No. That's what rebooting the system is for. Cleaning up after running
a bunch of apps that don't clean up after themselves. Its a problem
for the user that runs a bunch of badly written apps, a largely self
inflicted problem. Why is it a problem for you?

Joe Seigh

Florian Große-Coosmann

7/24/2004 6:54:00 AM

0

Joe Seigh schrieb:
>
> Florian Große-Coosmann wrote:
>
>>Hi,
>>
>>Regarding POSIX threads on Linux.
>>
>>We are developing a shared library for an interpreter which wraps
>>another shared library with state informations for each thread.
>>
>>Our wrapper needs to call a cleanup function on a per-thread basis.
>>
>
> ...
>
>>Is there a standardized protocol which should be used to get something
>>running (a finalizer routine) when a library needs to be cleaned up
>>in a MT environment without managing a list of involved threads by
>>our own starting from in to fini?
>>
>
>
> No. That's what rebooting the system is for. Cleaning up after running
> a bunch of apps that don't clean up after themselves. Its a problem
> for the user that runs a bunch of badly written apps, a largely self
> inflicted problem. Why is it a problem for you?

??? The problem is that we *don't* want to write badly written apps.
Cleaning up is a matter of the process' end, not of system termination.
We are not on a Windows box.

Let me explain it a little bit more understandable, hopefully ;-)

We write a wrapper for mysql.so (and for many other shared libraries,
so don't be picky about this target file). Opened requests in mysql
need to be closed, otherwise a resource won't get closed.

The user's language allows people to open a request, do some processing,
close the request. But the script may be stopped by some reasons and the
user is unable or not clever enough to intercept the suddenly following
close. The interpreter stops the thread and the problem is there.

What now? How to address most of the possible thread deaths at once to
do the cleanup? We may get an unlink request of our library, too. This
should be covered, too.

It is a philosopher's problem to push back the problem to the user.

A shared library should cleanup if possible from the conditions:
a) normal thread termination (relating the shared lib)
b) thread crash (relating the shared lib)
c) unlinking of the shared lib without proper cleanup by the user
of every thread

Note that cleaning up a process is no problem. The system's process
termination handling is sufficient.

Cheers, Florian

Joe Seigh

7/24/2004 1:42:00 PM

0



Florian Große-Coosmann wrote:
>
> Joe Seigh schrieb:
> >
> > No. That's what rebooting the system is for. Cleaning up after running
> > a bunch of apps that don't clean up after themselves. Its a problem
> > for the user that runs a bunch of badly written apps, a largely self
> > inflicted problem. Why is it a problem for you?
>
> ??? The problem is that we *don't* want to write badly written apps.
> Cleaning up is a matter of the process' end, not of system termination.
> We are not on a Windows box.
>
> Let me explain it a little bit more understandable, hopefully ;-)
>
> We write a wrapper for mysql.so (and for many other shared libraries,
> so don't be picky about this target file). Opened requests in mysql
> need to be closed, otherwise a resource won't get closed.
>
> The user's language allows people to open a request, do some processing,
> close the request. But the script may be stopped by some reasons and the
> user is unable or not clever enough to intercept the suddenly following
> close. The interpreter stops the thread and the problem is there.
>
> What now? How to address most of the possible thread deaths at once to
> do the cleanup? We may get an unlink request of our library, too. This
> should be covered, too.
>
> It is a philosopher's problem to push back the problem to the user.
>
> A shared library should cleanup if possible from the conditions:
> a) normal thread termination (relating the shared lib)
> b) thread crash (relating the shared lib)
> c) unlinking of the shared lib without proper cleanup by the user
> of every thread
>
> Note that cleaning up a process is no problem. The system's process
> termination handling is sufficient.
>

The OS doesn't provide mechanism for dealing with badly behaved threads
which can leak resources. And you are going to get a bunch of input
from others here on why you cannot or should not bother to recover
from thread crashes.

I suppose you could start your own process with a thread pool to act
as proxy threads for handling dll requests. You'd have the problem of
trying to determine whether you could safely return the results of the
proxy requests. Probably a APC callback. Kind of like Solaris
door calls.

Joe Seigh