Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Posix thread exiting and destructors

Reply
Thread Tools

Posix thread exiting and destructors

 
 
Gianni Mariani
Guest
Posts: n/a
 
      04-12-2007
James Kanze wrote:
> On Apr 11, 3:58 pm, Gianni Mariani <(E-Mail Removed)> wrote:
>
>>James Kanze wrote:
>>

....
>
> That's a separate issue. (In some cases, there's no need for a
> clean shutdown anyway. A shutdown is, by definition, unclean.)


The C++ does describe how a shutdown works. How is it unclean ?

>
>
>>This means (possibly other meanings too) that every thread
>>object must be deleted by a thread other than the thread itself before
>>exit from main.

>
>
> I think you're confusing the "thread" object with what the OS
> considers a thread. In fact, the "thread" object, here, is just
> a functional object which is called by the function whose
> address is passed to pthread_create. The OS knows nothing about
> it, and there's not the slightest problem with deleting it in
> any thread you chose, as long as you are sure that no other
> thread will use it. (In every case where I've used this idiom,
> no other thread has even had a pointer to this object, so no
> other thread could use it.)


I think I know what I meant. I have developed many heavily threaded
applications with C++ and my experience is that if you don't look after
shutting down, you will run into issues. The nastiest and most
difficult to debug is when you get an exception and the debugger points
to an empty page of memory. This usually happends when a thread is
executing some library code and some destructor is unloading a library
out from underneath another thread. While not impossible to debug, it
takes alot of repeated attempts to find which thread it is. Invariably,
the solution is to wait for the thread to complete before shutting down.


>
>
>>Creating a system that does otherwise will have you searching
>>for the elusive bug - I've been there too often - random
>>segv's on exit or shutdown of a threaded object.

>
>
> Exit is a special case, and needs to be handled, but it has no
> relevance here.


Special in what way ? Like strcpy does not check for the size of the
destination or sprintf buffer overruns are not important until you find
that 2/3 of the computers on the net are bots ?

>

....
> In at least one of the models being considered for
> standardization, a thread IS an asynchronous function (which
> possibly returns a type which can be used to get its return
> value later).


I assume you mean the "future" interfaces ? It's of limited value IMHO.
It can't be used to implement most of the applications I have
implemented. There was a project where we did try to use it a few years
ago and I think it didn't prove a rich enough interface.
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      04-13-2007
On Apr 12, 3:32 pm, Gianni Mariani <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On Apr 11, 3:58 pm, Gianni Mariani <(E-Mail Removed)> wrote:


> >>James Kanze wrote:


> ...


> > That's a separate issue. (In some cases, there's no need for a
> > clean shutdown anyway. A shutdown is, by definition, unclean.)


> The C++ does describe how a shutdown works. How is it unclean ?


I expressed myself poorly. What I meant is that many
applications are meant to run "forever", and that the fact that
they are not (they are shutting down) means that something wrong
("unclean") has occurred.

I'm generally sceptical of this attitude, and prefer to provide
a mechanism for a clean shutdown even in programs designed to
run forever, but I've seen a lot of servers which can only be
stopped by "kill -9", or something similar.

(And of course, C++ doesn't really describe how shutdown works
in every case. It partially describes what happens if you call
exit() in a single threaded program, but it doesn't say
anything---yet---about threads, nor about what happens if the
process is the target of a "kill -9".)

> >>This means (possibly other meanings too) that every thread
> >>object must be deleted by a thread other than the thread itself before
> >>exit from main.


> > I think you're confusing the "thread" object with what the OS
> > considers a thread. In fact, the "thread" object, here, is just
> > a functional object which is called by the function whose
> > address is passed to pthread_create. The OS knows nothing about
> > it, and there's not the slightest problem with deleting it in
> > any thread you chose, as long as you are sure that no other
> > thread will use it. (In every case where I've used this idiom,
> > no other thread has even had a pointer to this object, so no
> > other thread could use it.)


> I think I know what I meant.


Then why did you say something else?

> I have developed many heavily threaded
> applications with C++ and my experience is that if you don't look after
> shutting down, you will run into issues.


If you provide a clean shutdown. If you don't provide a clean
shutdown, and require a "kill -9" to stop the process, then you
don't run into those issues. (You may run into others; it all
depends on what you are doing.)

> The nastiest and most
> difficult to debug is when you get an exception and the debugger points
> to an empty page of memory.
> This usually happends when a thread is
> executing some library code and some destructor is unloading a library
> out from underneath another thread.


That's really independant of shutdown, I'd say. Pull the rug
out from under a thread, and you're going to have problems.
Destructing an object in one thread that another thread is using
isn't a good idea, regardless of where it happens.

> While not impossible to debug, it
> takes alot of repeated attempts to find which thread it is. Invariably,
> the solution is to wait for the thread to complete before shutting down.


No disagreement, really, but that has nothing to do with the
discussion at hand, and wasn't what you said before. In fact,
destructing the thread object in the thread, and not from
another thread, is probably the surest way of ensuring that the
object isn't destructed while the thread is still using it.

> >>Creating a system that does otherwise will have you searching
> >>for the elusive bug - I've been there too often - random
> >>segv's on exit or shutdown of a threaded object.


> > Exit is a special case, and needs to be handled, but it has no
> > relevance here.


> Special in what way ?


In that you don't expect to continue running, or handling
further requests, once it has been called. In that it will
never be called in a lot of servers.

> Like strcpy does not check for the size of the
> destination or sprintf buffer overruns are not important until you find
> that 2/3 of the computers on the net are bots ?


> ...
> > In at least one of the models being considered for
> > standardization, a thread IS an asynchronous function (which
> > possibly returns a type which can be used to get its return
> > value later).


> I assume you mean the "future" interfaces ?


Yes.

> It's of limited value IMHO.


It depends on what you are using threads for. For my
applications, it's not very useful, no. In fact, my threads are
normally detached; they correspond more to a void function which
executes asynchronously.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
 
 
 
Gianni Mariani
Guest
Posts: n/a
 
      04-13-2007
James Kanze wrote:
> On Apr 12, 3:32 pm, Gianni Mariani <(E-Mail Removed)> wrote:
>

....
>
>>I assume you mean the "future" interfaces ?

>
>
> Yes.
>
>
>>It's of limited value IMHO.

>
>
> It depends on what you are using threads for. For my
> applications, it's not very useful, no. In fact, my threads are
> normally detached; they correspond more to a void function which
> executes asynchronously.


Invariably I find myself needing many of these "things" in one process
space for various reasons ranging from stress tests to scaling. The so
called short cuts to not design a consistant shutdown cause more
problems than it's worth. Server designs that appear like simple
classes so the objects can be created and destroyed at whim make for
very stable systems and easily embeddable in all kinds of ways. It's
kind of hard to kill -9 the object.


 
Reply With Quote
 
bjeremy
Guest
Posts: n/a
 
      04-13-2007

Boltar wrote:

> I would have multiplexed , but each connection will be sending lots of
> data and I waws concerned about write blocks. Just because the
> select() mask flag says the socket is ready to write doesn't mean
> it'll accept everything you throw. With multiplexing every socket
> would have to be non blocking so a blocked socket doesn't hang every
> other session and I'd have to keep tabs of retries etc. With threads
> I can just let a socket happily block and it won't affect anything
> else.
>


On a single processor, with using multiple threads to handle your
connections, the effect is a lot of context switching. And using
blocking I/O (opposed to non-blocking io) is also another unecessay
bottleneck that would slow down you server. If your design allows for
it, you may want to use seperate send and receive sockets... but I
understand that not every design can do this, depending on your
application.. With sends, you would just send the data, and if you
catch a signal, just re-try the send.. don't even bother keeping track
of re-tries.
Anyway, I don't have the books in front of me at the moment, but
Stevens, "Unix Network Programming vol 1", talks about different
server types and their pros and cons... also there is a good
discussion about performance of different server tyoes in this
O'reilly book "Java Network Programming"

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How can I kill a running thread when exiting from __main__ care02@gmail.com Python 5 04-03-2007 06:05 PM
Cleanly exiting multi thread application on SIGINT jrpfinch Python 2 03-23-2007 01:32 PM
Problem creating new posix thread darklupine C++ 6 11-26-2005 08:13 PM
Posix Thread : C++ : poiinter to Member function raxitsheth@gmail.com C++ 2 05-13-2005 02:38 PM
Posix Thread Wrapper [HELP!!!] Sebastian Kloeppel C++ 3 04-17-2004 04:08 AM



Advertisments