Re: SDL_KillThread()

Previous Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Re: SDL_KillThread()

Bob Pendleton
On Wed, 2003-12-03 at 00:16, Miles Vignol wrote:

> Sent: Tuesday, December 02, 2003 8:25 PM
> > Well, the Bob's way is *the* standard for terminating threads. It's
> > always better for a thread (and even a process, remember atexit()) to
> > know that it is being killed. For a thread it is especially important
> > because it usually shares a lot of resources with other threads (this is
> > one of the main reasons why we use threads instead of processes, don't
> > we?) and you want it to do something meaningful to them before it ends.
> > These are the examples of resources you have to think of before
> > terminating the thread:
> >
> > 1. Memory (of course)
> > 2. File descriptors (unlike processes, automatic thread termination
> > cannot just close them, because they were not duped).
> > 3. Synchronization resources. In addition to necessity to determine
> > whether or not to destroy them or otherwise indicate you are done with
> > them (as for example decrease reference counter), you need to decide
> > what to do with the locked mutices (unlock'em all?), signalled
> > conditional variables (wait for'em?), counting semaphores (reset'em?),
> > critical sections etc.
> yeah, i've actually implemented a memory system to handle the memory
> freeing.  when i kill a thread, i free the "private" memory that thread
> allocated (i've set up special routines to allocate "private" memory that
> only that operation needs to know about -- when i signal the thread, i then
> clean up after it).  i can probably handle any file descriptors in the same
> fashion, but it's the critical sections that are killing me -- no pun
> intended.  when the thread is brutally slain by SDL_KillThread i have
> absolutely no control over where it gets killed.  that i'm aware of...
> hmmm... maybe i can have a mutex handle this...
> here's a thought.  when i enter critical sections i could set a mutex.
> actually i already do, but maybe another more generic one.  this mutex would
> be checked when i want to kill a thread.  i think this may work for me....
> that way, i know that i'm not in a critical section, and if i am, the killer
> would block until the particular thread has left the crit section.

Two words "race condition".

                        Bob Pendleton

> >
> > It is obvious that these decisions are mostly application-specific and
> > such as a-la signal handler for a thread would have to run in a separate
> > context of execution anyway, any operation with such intimate shared
> > memory resources would have to be synchronized between the thread and a
> > signal handler which is not impossible but pretty expensive. So having
> > the "done" state is probably the lesser evil. From a practical point of
> > view, each thread that is supposed to run for a relatively long time
> > (like ~50 milliseconds or longer), must have a loop somewhere and it is
> > often a convenient place to put a check for the "done" flag. For the
> > threads that are not supposed to run 50 milliseconds you probably won't
> > bother killing them (they will die themselves).
> people keep telling me to have a flag, but i just don't like the idea of
> having a bunch of "should i stop?" checks in my code.  particularly if
> there's no way to exit from a thread anyway.  i'd have to hit the "breaks"
> (okay, this one was intentional) in all my loops and just drop out of nested
> function calls till the functions returned.
> > On the other hand, in Windows (more exactly, Win32), (almost?) all
> > resources are thread-safe "out of box" (for example, you do not have to
> > lock a mutex to signal on event or wait for it) so that an additional
> > synchronization by the app is not requried, therefore thread kill makes
> > more sense. It comes at a price of lower efficiency, of course -- or so
> > it should be :-)
> it's the thread-safe nature that's getting me.  the memory allocation
> routines lock out other threads, but if the thread is killed before it
> unlocks, no other thread can get into the necessary routine and i get a
> deadlock.
> -miles vignol
> _______________________________________________
> SDL mailing list
> [hidden email]
+ Bob Pendleton: writer and programmer. +
+ email: [hidden email]              +
+ web:         +

SDL mailing list
[hidden email]