On 1/12/06, Sergey Semenov <sergey.semionov@xxxxxxxxx> wrote:
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
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/
