[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sock_recvmsg() blocks and is not killable
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,
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/