RE: Sock_recvmsg() blocks and is not killable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
 
 


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

Hi Jitesh,

 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/



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux