Lazyweb: of the good usage of GSource...
Par liberforce le jeudi 21 février 2008, 19:19 - Computers / Informatique - Lien permanent
I'm currently writing an application that has two backends.
- In live mode, I acquire images from several cameras.
- In replay mode, I read pre-recorded images from the hard drive.
As I want to switch between these 2 backends transparently, I thought of using two implementations of a custom GSource. It seemed to be what I need: a way to send and react to asynchonous events. In my case, I want to notify the application that the images are in the memory, and ready to be processed.
However I'm a still a bit puzzled about how GSource works, and I found the documentation a bit obscure to people unfamiliar with the arcanes of the glib main loop. The timeout and idle sources don't give me enough information. The other examples use polling of file descriptors, but I have nothing to poll here. I've even checked out The Official GNOME 2 Developper's Guide, but no GSource there. I had not much result in the gtk-apps-devel mailing list, nor the french GTK forums.
I'm at the point where I'm not even sure that GSource meets my needs, but I wanted to avoid as much as possible exposing the acquisition backend. There will be multi-threaded stuff for live acquisition (the cameras I'm using only provide a blocking API, sigh..), but they're not required for the replay mode.
Do you think a custom GSource is the way to go ? It seems it's the only way I can connect to glib's main loop to receive asynchronous events (excepted from timeout and idle sources). Could someone please explain me a bit in which case(s) using GSource is recommended ? Thanks for reading.
Commentaires
It sounds like you are putting the abstraction at too low a level.
How about defining a GInterface with the relevant signals and methods, and then implement that for your two cases?
If there is a lot of common code shared between the two cases an abstract class could do the trick to.
If you use threads, just make sure to emit the signals in an idle handler to make sure it is processed in the main loop.
Thanks for your advice Mikkel, I didn't have heard about GInterface before. But working on this problem again made me choose another solution. I thought at first that the API of my cameras was synchonous only, but in fact it can be used in an asynchronous way, and I can use the glib main loop instead of different threads. So I'm going to use a classical state machine managed in an high priority idle handler. This handler will take care of the actions to perform: acquisition/data extraction/data processing steps. This solution also allows me to simplify my code, and makes me worry less on software synchronization of image acquisition (I wasn't sure every GSource would have been processed all in a row).