Sandeep,
The
while() just has reduntant check added to make sure the packet
received is valid. Actually recv() performs a few UDP port checks, address
checks and if any thing goes wrong it returns zero as the length of the
packet. And since only a few packets are received, most of the time, recv()
function stalls rather than the process eaten up in while
loop.
Regards
Hi Jitesh,
From: K S Sandeep [mailto:kssandeep@xxxxxxxxx]
Sent: Tuesday, January 31, 2006 10:13 PM
To: Jitesh Shah
Cc: Jan Hudec; Adil Mujeeb; kernelnewbies@xxxxxxxxxxxx
Subject: Re: Sock_recvmsg() blocks and is not killable
If ur saying that the recv( ) is blocking, then why have you added the while loop. I am not clear with this. The code looks as though the while loop is blocking it, rather than the recv( ) itself. U also mention that u have very few packets to receive, and u r on an embedded environment, then why a while loop. This could affect ur other task, if any. The CPU will be utilized by this task more often than necessary.
correct me if i am wrong, as i am not clear with ur requirements.
regards
Sandeep
On 1/31/06, Jitesh Shah < jitesh.shah@xxxxxxxxxx> wrote: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/
