Why you should never suspend a thread

RE: Why you should never suspend a thread

Jack Mathews — Tue, 09 Dec 2003 18:58:00 GMT

Q: How does one typically make an object threadsafe? A. Working off of the stack rather than the heap, thread local storage, and critical sections. (I know you're looking for critical sections :) ) Q: What is the result of suspending a thread in the middle of a threadsafe operation? Critical section never gets unlocked if you're inside it. Q: What happens if - subsequently - you try to access that same object (in this case, the console) from another thread? Deadlock... -- One thing, btw, that suspendthread is good for, and perfectly safe, is for a thread to suspend _itself_. That's been a useful tool to me in the past, and probably the only OTHER useful purpose of it.

RE: Why you should never suspend a thread

bryan — Wed, 10 Dec 2003 13:25:00 GMT

since you're on processes here (this is 99% off-topic) if you have a process that passes an uri to the system's protocol handler (this is an asynchronous pluggable protocol that's being passed, a self-rolled one, but it could be http:, outlook: , etc.) can one find out what process the uri was passed from by knowing what the uri is?

RE: Why you should never suspend a thread

Raymond Chen — Wed, 10 Dec 2003 19:40:00 GMT

Sorry, I don't understand the question. Who is "one"? The process that is responsible for handling the protocol? If you choose DDE as your protocol invocation mechanism, I believe DDE lets you determine who is on the other end of a DDE conversation.

RE: Why you should never suspend a thread

Ben Wilhelm — Thu, 11 Dec 2003 05:43:00 GMT

I had a bug on this exact matter - I was suspending a thread, and it was ending up in the middle of a memory allocation mutex. Grrr. Useless function - totally useless. I've always been trying to think of a way to do SuspendThread() without having to make the thread poll constantly, but have never managed to come up with one.

RE: Why you should never suspend a thread

Jack Mathews — Thu, 11 Dec 2003 06:11:00 GMT

1) Not useless. Again, if used by the thread itself, it's extremely useful. 2) Well, there's always going to HAVE to be some way to poll. A way would be to put the unsafe code in critical sections, and make the thread that suspends your thread is also enter the critical section. Then you can guarantee that only when you're out of it can the suspend get called. But in this case, you may as well just poll in a safe place, rather than this.

RE: Why you should never suspend a thread

bryan — Thu, 11 Dec 2003 14:10:00 GMT

'Who is "one"? The process that is responsible for handling the protocol? If you choose DDE as your protocol invocation mechanism, I believe DDE lets you determine who is on the other end of a DDE conversation.' The one was grammatical, as in any unnamed individual, or I guess process as well in this case. The problem I'm thinking about specifically is that I've rolled my own pluggable protocol in a third-party scripting language, and registered it as such via the registry, this language however has no understanding of DDE, and no especially easy way of implementing it, I can however pass off the protocol information via the command line and using Standard I/O get information back, so what I'm wondering (and I figure it's probably not doable) is there anyway for a third process to work out from just the protocol information, what process invoked the uri. Sorry for taking up the time on your blog with this, but I figure there are not very many people out there competent to answer this question with either an authoritative no, or a 'read these 15 links' yes.

Script And IE Security Part Seven: Other Stuff

Fabulous Adventures In Coding — Thu, 22 Jan 2004 21:20:00 GMT

Dessecting The Stack Part3 ------- Walking The Callstack

AdvDbg System Section — Tue, 15 May 2007 08:00:37 GMT

Breaking The Secrets ----- Dessecting The Stack Part3 Walking The Callstack Last time I cover much...