it’s documented that SDL_KillThread() is meant pretty much for extreme circumstances. so how, then, do you kill a sub-thread? on windows, there’s no kill() function to send a signal to a particular thread. if a do a raise() function, it seems to only signal the SDL_Main thread. and even if it signaled other threads as well, how can i keep the SDL_Main thread from acting on that signal?
-miles vignol
fathom entertainment
it’s documented that SDL_KillThread() is meant pretty much for extreme
circumstances. so how, then, do you kill a sub-thread? on windows,
there’s no kill() function to send a signal to a particular thread.
if a do a raise() function, it seems to only signal the SDL_Main
thread. and even if it signaled other threads as well, how can i keep
the SDL_Main thread from acting on that signal?
Have a global “done” variable that the thread checks on a regular basis.
Before you create the thread you set done to false, when you want the
thread to quit you set done to true. Doing that lets the thread do any
clean up it needs to do before it terminates. After you set done to true
(stopping the thread) you want to use SDL_WaitThread() to wait for the
thread to quit.
The gotchas are that you have to make sure the thread isn’t blocked
somewhere keeping it from checking the “done” variable. For example, if
the thread can block trying to queue something then you have to make
sure the queue will eventually empty enough for the thread to finally
add something to the queue. Or, if it is waiting on a semaphore or
condition you have to make sure that it gets past the wait so that it
can check the “done” variable and quit.
In other words, you need to design your code so it can be shut down. You
need to know the states a thread can be in when the program needs to
shut down.
Bob PendletonOn Tue, 2003-12-02 at 04:00, Miles Vignol wrote:
-miles vignol
fathom entertainment
–
±--------------------------------------+
Have a global “done” variable that the thread checks on a regular basis.
Before you create the thread you set done to false, when you want the
thread to quit you set done to true. Doing that lets the thread do any
clean up it needs to do before it terminates. After you set done to true
(stopping the thread) you want to use SDL_WaitThread() to wait for the
thread to quit.
Bob Pendleton
i was sorta hoping to avoid having to check a status flag. i prefer an
interrupt method via signals, but i must admit i’m a bit out of my depth on
this one.
if i had a friggin’ kill() equivalent in windows, then i’d be a happy
camper. i just don’t understand the usage of raise() nor do i get the
signal() management of sub-threads. it seems as tho my sub-threads don’t
receieve the signal i’m sending…
maybe this is getting outside the scope of SDL, tho…
what is the standard way of telling a thread it’s time for it to end?
exit() ends the whole program. is there a standard way or is it OS
specific? would it make sense for SDL to have a generic version? like
SDL_ThreadDone() or something so that a thread can end itself in the OS
appropriate way…?
-miles vignolSent: Tuesday, December 02, 2003 5:33 AM
Have a global “done” variable that the thread checks on a regular basis.
Before you create the thread you set done to false, when you want the
thread to quit you set done to true. Doing that lets the thread do any
clean up it needs to do before it terminates. After you set done to true
(stopping the thread) you want to use SDL_WaitThread() to wait for the
thread to quit.Bob Pendleton
i was sorta hoping to avoid having to check a status flag. i prefer an
interrupt method via signals, but i must admit i’m a bit out of my depth on
this one.if i had a friggin’ kill() equivalent in windows, then i’d be a happy
camper. i just don’t understand the usage of raise() nor do i get the
signal() management of sub-threads. it seems as tho my sub-threads don’t
receieve the signal i’m sending…
Doesn’t SDL_KillThread() work under windows? I’m pretty sure it does.
Just use that if all you need is to kill a thread with no clean up. This
is dangerous, of course, because you could kill a thread that has a
resource locked and then never be able to access the resource again.
Otherwise you pretty much have to use a flag. The warnings about using
SDL_KillThread() are mostly based on long experience with programming
threads. It is just not a good idea to kill threads with out knowing
where they are or what they are doing.
maybe this is getting outside the scope of SDL, tho…
Yes and no. It is about how to do thread programming using SDL. But, it
is more about threads than SDL.
what is the standard way of telling a thread it’s time for it to end?
exit() ends the whole program. is there a standard way or is it OS
specific? would it make sense for SDL to have a generic version? like
SDL_ThreadDone() or something so that a thread can end itself in the OS
appropriate way…?
The normal way for a thread to end is for the subroutine that you passed
to SDL_CreateThread() to return. That is, just let the top level
function of the thread return. The SDL wrapper code takes care of any OS
specific stuff, though most thread packages handle this for you. So, you
see, there is no need to have “SDL_ThreadDone()” function.
-miles vignol
Bob PendletonOn Tue, 2003-12-02 at 13:58, Miles Vignol wrote:
Sent: Tuesday, December 02, 2003 5:33 AM
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+
Hello Miles,
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:
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).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 
Hope this will help, Pavel Miles Vignol wrote:
Sent: Tuesday, December 02, 2003 5:33 AM
Have a global “done” variable that the thread checks on a regular basis.
Before you create the thread you set done to false, when you want the
thread to quit you set done to true. Doing that lets the thread do any
clean up it needs to do before it terminates. After you set done to true
(stopping the thread) you want to use SDL_WaitThread() to wait for the
thread to quit.Bob Pendleton
i was sorta hoping to avoid having to check a status flag. i prefer an
interrupt method via signals, but i must admit i’m a bit out of my depth on
this one.if i had a friggin’ kill() equivalent in windows, then i’d be a happy
camper. i just don’t understand the usage of raise() nor do i get the
signal() management of sub-threads. it seems as tho my sub-threads don’t
receieve the signal i’m sending…maybe this is getting outside the scope of SDL, tho…
what is the standard way of telling a thread it’s time for it to end?
exit() ends the whole program. is there a standard way or is it OS
specific? would it make sense for SDL to have a generic version? like
SDL_ThreadDone() or something so that a thread can end itself in the OS
appropriate way…?-miles vignol
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Doesn’t SDL_KillThread() work under windows? I’m pretty sure it does.
Just use that if all you need is to kill a thread with no clean up. This
is dangerous, of course, because you could kill a thread that has a
resource locked and then never be able to access the resource again.
Otherwise you pretty much have to use a flag. The warnings about using
SDL_KillThread() are mostly based on long experience with programming
threads. It is just not a good idea to kill threads with out knowing
where they are or what they are doing.
yeah, but it’s bad. i’m getting deadlocks because of it. i need to kill a
thread, but have a little more control – like ignore the signal till i’m
outside of critical sections (or similarly protect against problems).
The normal way for a thread to end is for the subroutine that you passed
to SDL_CreateThread() to return. That is, just let the top level
function of the thread return. The SDL wrapper code takes care of any OS
specific stuff, though most thread packages handle this for you. So, you
see, there is no need to have “SDL_ThreadDone()” function.
i’m looking for something akin to “exit()”. if you had to exit a program as
the last statement in your main() function, it would be a bit limiting,
don’t you think? it seems that not implementing a way to have a thread end
itself is similarly limiting.
-miles vignol
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:
- Memory (of course)
- File descriptors (unlike processes, automatic thread termination
cannot just close them, because they were not duped).- 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.
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 vignolSent: Tuesday, December 02, 2003 8:25 PM
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.
In a nutshell, you have the reason why killing threads is a bad idea.
Welcome to the wonderful world of multi-threaded programming. Often,
it’s more efficient not to multi-thread.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
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.In a nutshell, you have the reason why killing threads is a bad idea.
Welcome to the wonderful world of multi-threaded programming. Often,
it’s more efficient not to multi-thread.
well, i’m back to using ThreadKill and just wrapping all the imporant calls
in mutex locks… we’ll see how it goes.
to think. this all started with me trying to animate the cursor.
i do think it would be nice to add the an explicit thread exit routine a la
pthread_exit() or EndThread().
-miles vignolSent: Wednesday, December 03, 2003 12:18 AM
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…
This is the main reason you shouldn’t use SDL_KillThread. The best way to
end a Thread is to return out of the function you’re passing to
SDL_CreateThread. The flag method is equivilent and likely more efficient
than the Mutex version you described, except that you don’t brutally kill
the thread at all, and that your reaper thread never blocks (so, it could
end more than one thread safely at once, perhaps) when a thread is in a
critical section.—
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.541 / Virus Database: 335 - Release Date: 11/14/2003
to think. this all started with me trying to animate the cursor.
By the way, you know you can only call video functions from the main
thread, right?
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
By the way, you know you can only call video functions from the main
thread, right?
yeah, it took me a while, but i figured that out. the main thread is the
gui and it spawns all my worker threads.
Doesn’t SDL_KillThread() work under windows? I’m pretty sure it does.
Just use that if all you need is to kill a thread with no clean up. This
is dangerous, of course, because you could kill a thread that has a
resource locked and then never be able to access the resource again.
Otherwise you pretty much have to use a flag. The warnings about using
SDL_KillThread() are mostly based on long experience with programming
threads. It is just not a good idea to kill threads with out knowing
where they are or what they are doing.yeah, but it’s bad. i’m getting deadlocks because of it. i need to kill a
thread, but have a little more control – like ignore the signal till i’m
outside of critical sections (or similarly protect against problems).
Yeah, and that is exactly what a flag does. It tells the thread to quit,
when it is ready to quit.
The normal way for a thread to end is for the subroutine that you passed
to SDL_CreateThread() to return. That is, just let the top level
function of the thread return. The SDL wrapper code takes care of any OS
specific stuff, though most thread packages handle this for you. So, you
see, there is no need to have “SDL_ThreadDone()” function.i’m looking for something akin to “exit()”. if you had to exit a program as
the last statement in your main() function, it would be a bit limiting,
don’t you think?
No, I don’t find it limiting at all. I find it very natural. Matter
of taste I suppose.
You could certainly use setjmp/longjump to leap back into the thread’s
top level function and then terminate. Not what you want, but it would
work.
it seems that not implementing a way to have a thread end
itself is similarly limiting.
Now we are walking into religious areas. I learned to program when the
religion of the day required you to not use goto, return, or exit.
Return and exit were supposed to be implied by reaching the bottom of a
function or program. The exit in the middle programming idiom is
considered to be a serious sin by followers of that religion. tOf
course, the proponents of that religion considered C to be blasphemous
and Pascal to be glorious. I was never a member of that religion but I
had to comply with it to graduate from college.
In my early working career I was forced to comply with the religions of
HIPO diagrams and Warnier-Orr charts which both discourage the exit in
the middle programming idiom. (I would rather write Warnier-Orr charts
than do eXtreme programming any day
The result is that I am perfectly happy programming without explicit
return or exit statements in a programming language and use them
sparingly and only withing certain coding idioms where they simplify the
code.
As a result of my early training I simply am not the least bit bothered
by the lack of a threadExit(). And, considering the kinds of design
horror it would allow I’m not sure I would use it if it existed.
Clearly you disagree, so there is nothing more for me to say on the
subject.
-miles vignol
Bob PendletonOn Tue, 2003-12-02 at 21:18, Miles Vignol wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+
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:
- Memory (of course)
- File descriptors (unlike processes, automatic thread termination
cannot just close them, because they were not duped).- 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 PendletonOn Wed, 2003-12-03 at 00:16, Miles Vignol wrote:
Sent: Tuesday, December 02, 2003 8:25 PM
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 beit’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
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+