how to kill threads in solaris

Any idea how to kill threads (not processes) in solaris?
I had checked the man pages for both kill and pkill to no avail.

You can't.

Any reason why?

Becasue that's not the way the kernel is written.

Removed post....missunderstood request

izy100, "kill" means "send a signal to". Signals get complicated real fast in a multi-threaded program. Best practice is for a multi-threaded process to have a dedicated signal acceptor thread (for lack of a better term) that has called sigwait. It then may invoke pthread_kill to signal some particular thread. Remember that if a thread who is not expecting a signal somehow gets one anyway, for the most part, one of two things will happen:

  1. the signal will be ignored
  2. the thread will behave as if it called exit(), thus destroying the entire process

In either case, it doesn't matter that much which thread was involved.

Threads cease to exist when they return from their main function or call pthread_exit. The thread is said to be cancelled. One thread can call pthread_cancel to try to cancel another thread. But threads may render themselves uncancelable. And processes rarely create superfluous or even expendable threads... in most cases, if one thread dies, the whole process must die with it.

tks for the info. I have a multi-threaded socket program that handles incoming connection from 100 clients. Each thread handles 1 connection and 1 client's request typically take < 5 seconds for a thread to handle before the thread perish.

Due to all types of reasons that happen over the past few years, e.g.: client program has bugs, issue with firewall setting btw the socket server and the clients, socket program has bugs, etc....., one of the common problem they caused is unclosed thread at the server server's end.

I am thinking if it is possible to write an external monitoring program that monitors for idle thread for > 5 seconds and send a signal to the thread to 'kill' it.

Perderabo, does that means my idea is undo-able?

I would try to think in terms of a monitoring thread rather than a monitoring process.

sorry for my denseness, what do you mean by, "monitoring thread rather than a monitoring process" ?

Sorry for my denseness, but I don't know how else to describe it.