Re: Posix thread exiting and destructors
On Apr 11, 10:38 am, "Boltar" <boltar2...@yahoo.co.uk> wrote:
On Apr 10, 11:00 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
On Apr 10, 4:49 pm, "James Kanze" <james.ka...@gmail.com> wrote:
It's also not too clear to me what kind of a class could want to
do an exit in its destructor. pthread_exit has semantics more
or less like throwing an exception, and that's generally
something you want to avoid in a destructor. Please explain
what you're trying to do.
Its a TCP server. Each incoming connection gets its own thread which
is encapsulated in a connection object. I would have just used fork()
but I want the threads to access some global stats and I couldn't be
bothered with the hassle of shared memory and associated locking
You will still have "locking" issues wether you use shared memory or
threads (where memory is implicitly shared).
True, but with threads you can use mutexes. You can't do that with
seperate processes (and despite what some people think you can't map
mutexes to shared memory since if the underlying mutex code uses
pointers you're screwed).
Some people, in this case, being the authors of the Posix
standard. See pthread_mutexattr_setpshared() in the standard,
for example. Note that this functionality is optional---as is
threading, for that matter. From personal experience, it is
present under Solaris and Linux, however, and I would expect it
to be fairly widespread.
I've used it under Solaris with no problem, with the mutex
itself in a mmap'ed file mapped into and shared between two
It's also true that the Posix standard (and the rationale) speak
of allocating memory on the heap, etc. in pthread_mutex_lock. I
suspect that this could only be made to work if thread
process-shared synchronization was not supported; at any rate,
it's the system's problem to make it work, not yours.
For processes you have to use SysV
semaphores (yuck) or a locking file (yuck again).
You have to have some memory which is common to the processes
involved. This can be shared memory, but I've found that
typically, mmap'ing is easier and works better.
... When the session is over or the remote client closes the
connection the thread has to exit and the object be destroyed.
Considered using a thread pool?
Can't be bothered :) Its not a high throughput server, the overhead of
creating/destroying threads to keep the code simple is worth it.
Yes. It's the sort of thing that if you already have the
existing code, why not, but it's not worth the hassle to develop
That's true until you try to exit. The main thread must wait until all
threads have cleaned up before it exits. You will have strange
behaviour if you don't.
If the parent thread ever exits other than via a crash it'll cause an
entire process halt so thats not an issue.
There's a lot that happens between the moment the parent thread
calls exit, and the moment the process actually stops running.
If other threads are running during that time, or at least if
they're doing anything non-trivial, you can sometimes get
surprising results. It's not too difficult keep count of your
threads, set a global flag for a clean shutdown, and wait until
the count is 0.
James Kanze (GABI Software) email:email@example.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34