Hi, On 1/26/06, Hsieh Steve <stevecfhsieh@xxxxxxxxx> wrote: > Thank alot for your replying!! > Besides, > Is there other way except to signal for kernel to notify a userspace > actively? I think that another way exists. But i don't know what i can recommend you else =) But i have another question. So, it seems that there are at least two directions(ways) of kernel-userspace message exchange: 1) Userspace application at every iteration can ask driver for new events (messages) using (blocked/unblocked) pool/select mechanism or ioctl and other system function calls. It's a good way, because you don't need to care about syncronisation and you can expect at what time the message comes. So you don't need any IPC staff to control your application (i mean critical sections and semaphores), 2) There is another way. The kernel can inform your userspace application about new events (e.g. through signals), but signals can interrupt the application execution at any time (like Hsieh Steve has described with recv() function) and you can't predict it at all.... Or can you? So, it was a small introduction =) My question is about: which solution is faster? The first way is very good, but if you want to achieve a good perfomance and fast message procceding, i think that the second way is more reasonable. Am i right? With best regards, Sergey Semionov -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
