Creating multi-threaded code to break locked/wait state

[Nayan]

Hi,

If I make a call to function which is in external library, and it goes
into wait sate.. disabling my app to proceed further, how can I break
this state elegantly? So far, I had to kill my process.

Someone suggested to code multi-threaded app in which one can monitor
other and if one goes into locked state, other kills it.

It sounds okay, but I don't know how to do it. Any code sample or
resources you can point me to, will be a great help!

Thanks a lot!!
Nayan

[JS]

I'm going to guess that you're calling this external library to get
some data when it becomes available. I'm also going to guess that as
soon as data is available the call will return from the waiting state.
My suggestion would be to put the call to the external library function
in a thread. When the call returns, put the relevant data into a queue
for other thread(s) to read.

Nayan wrote:

Hi,

If I make a call to function which is in external library, and it goes
into wait sate.. disabling my app to proceed further, how can I break
this state elegantly? So far, I had to kill my process.

Someone suggested to code multi-threaded app in which one can monitor
other and if one goes into locked state, other kills it.

It sounds okay, but I don't know how to do it. Any code sample or
resources you can point me to, will be a great help!

Thanks a lot!!
Nayan

[Jon Skeet [C# MVP]]

Nayan <cn****@gmail.comwrote:

If I make a call to function which is in external library, and it goes
into wait sate.. disabling my app to proceed further, how can I break
this state elegantly? So far, I had to kill my process.

Someone suggested to code multi-threaded app in which one can monitor
other and if one goes into locked state, other kills it.

It sounds okay, but I don't know how to do it. Any code sample or
resources you can point me to, will be a great help!

Well, while using another thread would let you abort the thread,
killing the process is a safer bet. If the external library has hung in
some way or other, you should regard the process as essentially
unstable. Simply aborting a single thread could leave other threads
created by the library, or resources unreclaimed etc.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Nayan]

The scenario is that the external lib function is reading from remote
server. If the server is unable to respond, then my app (being
synchronous call), gets hung.
Killing the process is "okay" solution, though its not the fault of my
app.

JS has assumed correctly all the things.
I liked the idea of JS. I'll try to follow it.

>>Simply aborting a single thread could leave other threads created by the library, or resources unreclaimed etc.

True, but then its better to kill a thread than aborting the whole flow
of application. Threads can be managed if the dependency is low between
them.
Any further suggestions? Thanks for all the efforts :)

Regards,
Nayan

[Willy Denoyette [MVP]]

"Nayan" <cn****@gmail.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.com...

The scenario is that the external lib function is reading from remote
server. If the server is unable to respond, then my app (being
synchronous call), gets hung.

The lib function should time-out if the remote server is not able to respond, but it should
not let there caller hang indefinitely. So the only real solution is fix this code.

Killing the process is "okay" solution, though its not the fault of my
app.

JS has assumed correctly all the things.
I liked the idea of JS. I'll try to follow it.

>>>Simply aborting a single thread could leave other threads created by the library, or
resources unreclaimed etc.

True, but then its better to kill a thread than aborting the whole flow
of application. Threads can be managed if the dependency is low between
them.

No, it's not, because you can't abort a *managed* thread that is currently executing or
blocking in unmanaged code., all you can do is call Win32's "TerminateThread" API through
PInvoke and terminate the OS thread associated with the CLR thread, but doing this is
dangerous and should only be done when you know precisely what the thread was currently
doing (in unmanaged code), that is, you need at least an answer to the following question
(among others):
- what locks is the thread currently holding?
Most of the time (if not always), you can't answer this question, which leaves you with only
one option: kill the process.

Willy.
Willy.

[Nayan]

That's terrible. I mean, I didn't design the external lib, so I can't
control the behaviour of the functions.

If that code cannot be fixed, what should I do? Move to another lib? It
also takes long to change the code.

*Sigh* Is there no alternative except killing my proc? :(

Nayan