On 1/25/06, Hsieh Steve <stevecfhsieh@xxxxxxxxx> wrote: > Hi, I have encountered the same problem ,too > (I mean, notify userspace app some event occurring form kernel space code) > AFAIK, the kernel can nofity a userspace app by signal or netlink > in my case, the netlink is not conpiled in, so the only way left is signal > Is there other way for kernel to notify a userspace actively?? > and Why is it a bad idea to use signal in such a case? > > BTW, I have another question about signal, > in my case , a process is forked to do some auth protocol handshaking > the process wake up , perform handshake (might be blocked in recv() or > select() system call) > when a systemV msg sent to it, > And a signal handler is registered to this process to recv some notification > from kernel, > All that signal Handler to do is just add msg to process's msg queue > I find that : when the process blocked at recv() and the signal comes, the > signal handler add msg to process's msg queue .and then it also wake up the > process even through the recv() not get a ready packet!! This is because recv() system call puts your process is put to sleep in TASK_INTERRUPTIBLE state and is waked up whenever there I any signal for process (does not matter if the actual event you were waiting occured or not). To handle this, check the return value of recv() system call, if it returns an error ERESTARTSYS, you are waked up by a signal and not the actual event. In this case you should again make recv() system call. > I solve this problem by masking the signal before invoking recv(). and > unmask it when recv() retuen a packet..... > > Why?? > > Steve. > > > 2006/1/12, MHD.Tayseer Alquoatli <idoit.ief@xxxxxxxxx>: > > > > > > > > > > On 1/12/06, Sergey Semenov < sergey.semionov@xxxxxxxxx> wrote: > > > Hi, > > > > > > Thank you for fast reply. > > > > > > On 1/12/06, Thomas Petazzoni < thomas.petazzoni@xxxxxxxx> wrote: > > > > > I've implemented driver, which waits for some event from external > > > > > device. When this event comes, i should notify ASAP my user-space > > > > > application from kernel to achieve the fastest reaction. Now i am > > > > > using only signals and i don't know what i can do else. Can you > advice > > > > > me something ? Thank you! > > > > > > > > If your application is waiting an event from a device, then it means > > > > that it called something like read(), write() or ioctl() which are > then > > > > implemented in the kernel space driver. These functions can sleep in > the > > > > kernel space driver until the event occurs. Then, they are unblocked > and > > > > the userspace process can continue its execution. > > > > > > Yes, exactly! But im my case, user-space application does another > > > background work everytime. It has own timetable with some events. In > > > infinite loop this application checks for next point execution time > > > and executes corresponding events. > > > > > > My driver is working concurrently with this application. Driver is > > > waiting for some external events, and if they occure, it informs the > > > application about this event using signal. When the application > > > catches this signal, it asks for driver about occured event using > > > ioctl function, schedules this event in own timetable and continues > > > execution. > > > > > > Sorry for such careless description, but i hope you'll understand what > > > i mean. Thus i can't use the blocking IO operations like you offered > > > above. And i don't know how to make this communication faster and in > > > more efficient way. > > > > > > you can use poll/select mechanisms to assure that such a blocking > operations will not block your calls > > you can probe for events from your device and continue to do your > background job if there is no events to serve then probe again later.. and > you can use timeout as well if your background job has a periodic nature > > see: > > http://www.die.net/doc/linux/man/man2/poll.2.html > > http://www.die.net/doc/linux/man/man2/select.2.html > > hope it helps > > > > MHD.Tayseer > > > > > > > Thank you! > > > > > > 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/ > > > > > > > > > > > > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
