views:

69

answers:

2

Hi All

I have a separate thread ListenerThread having a socket listening to info broadcasted by some remote server. This is created at the constructor of one class I need to develop.

Because of requirements, once the separate thread is started I need to avoid any blocking function on the main thread. Once it comes to the point of calling the destructor of my class I cannot perform a join on the listener thread so the only thing I can do is to KILL it.

My questions are:

  1. what happens to the network resoruces allocated by the function passed to the thead? Is the socket closed properly or there might be something pending? ( most worried about this )

  2. is this procedure fast enough i.e. is the thread killed so that interrupt immediately ?

  3. I am working with Linux ...what command or what can I check to ensure that there is no networking resource left pending or that something went wrong for the Operating system

I thank you very much for your help

Regards MNSTN

NOTE: I am using boost::thread in C++

+1  A: 
  1. Network resources belong to the process, not the thread, so the socket is still open.

  2. boost::thread does not have a kill method. You can only interrupt it. The effect is not immediate and depends on OS scheduler.

  3. For looking at what network resources a process holds check out lsof and netstat(8) with -p option.

The stop-signaling issue with blocking sockets as you describe is usually solved with the self-pipe trick.

Nikolai N Fetissov
Thanks Nikolai!can you confirm that even If I use PTHREAD , I have the same the problem using pthread_cancel or pthread_kill or other functions ? Same self-pipe trick must apply because of the network-resources-in-OS, right?
I wouldn't say *must*, but it will work the same (`boost::thread` is implemented with PThreads on Unix.)
Nikolai N Fetissov
+2  A: 

When you are killing a thread, you can't be sure what resources it holds. For example, it might be holding the heap mutex; if you kill the thread, the mutex will stay locked and nobody (in your process) will be able to allocate dynamic memory, ever.

It's much better to do these things by peaceful consensus than by force. Just add a way to signal to your thread that it's not needed anymore. It can be a boost::condition. The thread would check this condition and stop when it's signalled.

atzz
HI ATZZ. Thank you for your response. In my code actually I don't have any mutex at all..do you think that still it is better to use a boost::condition than to kill the thread with boost::thread::interrupt()?
I'm not sure if boost::thread has something similar, but the pthreads API supports pthread_atexit() specifically as a way for a thread to release resources it's managing as the thread terminates. Think of pthread_atexit() as similar to a "last will and testament" for the thread.
Chris Cleeland
@Chris Cleeland -- You mean pthread_cleanup_push()? It can help with resources you control explicitly, but what with resources you use implicitly (in the implementation of a library you use), or system resources?
atzz
@user311906 -- if your thread is using system calls, it can be acquiring and releasing some internal system resources. `boost::thread::interrupt` should be safe, but it's basically same thing as a manually-managed `boost::condition`. It can only be detected at "interruption points", and won't interrupt a thread blocked on a system call.
atzz
@atzz - you're correct regarding pthread_cleanup_push(); pthread_atexit() must've been part of an earlier or alternative implementation. To answer your question, though, you can't do anything about resources you don't own. Sockets, OTOH, are resources you own. Like boost::thread::interrupt, pthread_cancel() only interrupts at safe cancellation points. Manually managing the lifecycle of threads often doesn't work out the way we really want.
Chris Cleeland