Messages in this thread | | | Date | Fri, 29 Jun 2007 00:52:56 +0530 | From | "Satyam Sharma" <> | Subject | Re: [PATCH] RFC: have tcp_recvmsg() check kthread_should_stop() and treat it as if it were signalled |
| |
Hi Oleg,
On 6/28/07, Oleg Nesterov <oleg@tv-sign.ru> wrote: > On 06/28, Satyam Sharma wrote: > > > > Second, we *must* break that tcp_recvmsg() inside the kthread's > > main loop, of course! We want it stopped, after all, and if we don't > > make it "break" out of that function, the kthread _will_never_exit_. > > In that case this kthread is buggy. We have sock->sk_rcvtimeo. > > > Please note that this > > whole thing is about functions that will _simply_*never*_exit_ever_ > > _unless_ given a signal. > > ditto. kthread should not do this.
Well, I definitely wouldn't call it "buggy" ... skb_recv_datagram() (if with sock->sk_rcvtimeo != MAX_SCHEDULE_TIMEOUT) would then needlessly have to be put into it's own little while(1) (or put a "continue;" after it back to main kthread loop). A question arises, what timeout value to use? (too little => needless wastage of CPU; too high => see below)
More importantly, the other thread that does a kthread_stop() on our kthread (probably a umount(2) or rmmod) would then unfortunately hang (on wait_for_completion i.e. TASK_UNINTERRUPTIBLE) for the duration of the time it takes for our kthread to finish it's timeout, which plays havoc with userspace scripts.
> OK, I suggest to stop this thread. I don't claim you are wrong, just > we think differently ;)
That's fine, we can still "agree to disagree" here :-)
Cheers, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |