On Mon, Jan 22, 2007 at 02:06:10AM +0200, Rafi Cohen wrote: > Hello, I'm new in this list and I apologize in advance if my questions > are too basic. > I'm writing an application which "talks" with a number of test devices > connected to a gpib card and I'm using for this the open source linux > gpib driver (http://linux-gpib.sourceforge.net). > This is a multithread application, each thread for each device as each > device has it's own device descriptor to read from and write to it. > Within various states of the state machine of each thread, I need to > implement a look, sending a query to the device for it's current state > and reading the response. > The loop may end in 2 ways: either the device has transitioned to a new > state or timeout has occured and no transition happened during this > time. > Those timers are my problem here. The timers may vary within a thread, > depending on the expected state and, each thread has to have it's own > timers independent of the other threads. > I cannot implement this by using alarm, setitimer and getitimer as they > are process wide and not thread safe. > So I wonder if libevent may be the appropriate tool to help me implement > those timers.
It sounds like libevent is not what you need. For libevent to even be an option in your scenario, your device descriptors must be pollable and capable of operating in non-blocking mode. But, if they're pollable that begs the question of why you're using an asynchronous alarm. Assuming you require the asynchronous alarm/timer, why not do it yourself? You only need one timer for the entire process. For example, install a timer with an interval which is the minimum precision you would need to service a timeout for any blocking operation in any of your threads. Block that interval timer's signal in all threads but the alarm multiplexing thread. Then, manually call pthread_kill()--from the multiplexing thread--for each thread which requested a timeout. Using, of course, a different, non-blocked signal number so the other threads can receive it. Of course, the implementation isn't trivial. Dealing with signals alone, or threads alone, is difficult enough. Running a libevent loop in the multiplexing thread in order to take advantage of the signal synchronizing behavior (libevent sends signals down a pipe(2) so they can be dealt with more safely) might be an option. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
