Hi Jan, Thankyou so much for writing on this thread. Actually I think you wouldn't have quite read the earlier postings. I had posted the entire code. I have tried to unlock the signals. However, I am using the blocking mode of recv_msg, this keeps waiting until it receives a packet, even after it is sent a SIGKILL and doesn't allow me to check the pending signal. I am not sure if in blocking mode, this function waits and in perhaps not interruptable state. I was looking it there are any solution/fix/workaround for this problem. Could you please refer to earlier mails on this thread Regards Jitesh > -----Original Message----- > From: Jan Hudec [mailto:bulb@xxxxxx] > Sent: Saturday, January 28, 2006 3:07 AM > To: Jitesh Shah > Cc: Adil Mujeeb; kernelnewbies@xxxxxxxxxxxx > Subject: Re: Sock_recvmsg() blocks and is not killable > > On Fri, Jan 27, 2006 at 14:25:44 +0530, Jitesh Shah wrote: > > Hi, > > > > I am using the "kill_proc" function to kill the thread. > This is called > > from the main thread, which had created this process. If you can > > please go to the first posting, the entire code is listed there. > > > > void stop_client(void) > > { > > If(g_pid != -1) > > { > > lock_kernel(); > > killproc(g_pid, SIGKILL, 1); > > unlock_kernel(); > > } > > } > > Note, that kernel threads are never going to handle signals. > Even SIGKILL. > That is because signals are ONLY handled during return to > userland -- and kernel threads don't have userland to return > to. Also I believe signals are blocked by default in kernel > threads and you have to unblock them (I don't recall exactly > how, but you should find it in this list archives somewhere). > Then recv_msg should return upon receiving the signal, but > it's caller has to check what signal actually arrived and > arrange the thread to exit. > > -- > Jan 'Bulb' > Hudec <bulb@xxxxxx> > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
