Hi Toni.... > i've tried to do that, the problem is that witho non-blocking IO i > must sleep after the sock_recvmsg() function. IMHO, sleeping after sock_recvmsg() will increase the chance of getting more data on the next round of loop or just simply delaying the loop, so there is no obligation to put a sleeping delay here (btw, this is indeed a process context, right?) > my thought is performance will be limited in that case, it's correct? Well, sometimes yes, sometimes no. If the expected data will come rapidly, surely putting a sleeping delay will limit the perfomance, but if it is not, I think it won't hurt too much. Again, this is all depends on your goals when writing the code. > in my example it works fine with 1024 (the exact size of the struct > copied in the udp data field). This is something that I am not really sure. If sock_recvmsg is told to fetch 1024 byte of data, what will happen if there is only...let's just say...512 byte...the process will still sleep? And the sleep state of the process itself, what is it? is it uninterruptible? or interruptible? > i can't understand the use of functions from the linux/kthread.h > file, neither of them can wake a thread... any help? I don't think I can lend further help on giving ideas about kthread helper library. All I see briefly there, it is a wrapper for standartizing the creation, handling and destruction of kernel thread. As you know, in 2.4.x there are many ways kernel developers take to create and manage kernel thread, so uniformity plays a role to ease the code maintainance IMHO. They can'y wake your thread? Of course they can't, because you need to follow the "kthread.h" style since the beginning of creating your kernel thread and that's not the real problem. Actually the problem is (from what I see so far) how to put the kernel thread back to the run queue so it can be killed gracefully. About checking pending signal manually, of course you can always manually do that. But looking at the fact that somehow delivering the signal doesn't wake your kernel thread makes me guess that it is put on uninterruptible sleep. So, what is the solution? I suggest to take a deep look on how sock_recvmsg() works and find the way to "escape" if the expected data doesn't arrive (or they don't come as many as you expected). But, as easy workaround, using non blocking version coupled with schedule_timeout or msleep will do what you need IMHO. Hope the above ideas help you, regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
