Hi!
What is the recommended way of raising an event from a threaded member function?
Preferably a native solution.
My my main.cpp, I have one class that in a threaded function continuously grabs frames from my webcam and puts them in a buffer.
Then I have a class that handles socket stuff. Also a threaded member function
What I want is to have the socket class to be able to "ask" the camera class for an image.
Does that make sense?
Any help appreciated
//John
Last edited by John Erlandsson; 04-17-2012 at 08:55 AM.
Do you have any inter-thread communications now? Or are the threads currently running independently? Who is using the buffer with the frames now?
gg
Actually it is a pipeline of several image processors. They all have an in buffer and an outbuffer. The inbuffer is a pointer to another classes outbuffer. The outbuffer of the last processing class gets displayed in the main loop
The socket class has nothing to do with the image processing classes at the moment.
This seems backwards.
If the camera is constantly producing input the filter chain should be well fed.
Even if the filter chain isn't well fed, you kind of have to assume that the camera is doing the job you've put it to doing. With that in mind, why would the filter chain just not wait until the camera says "Hey, you, filer chain, I have another frame for you!"?
Soma
The chain works that way.Originally Posted by phantomotap
What I need is a way for the socket thread class to tell main that it needs a fresh frame from the pipeline.
The pipeline has a constant flow of images, but the socket class only needs a single frame when the client asks for one.
Is the question clear enough?
//John
My only experience int this field is Qt's signal/slot.
Something like that would be awsome, but i want to keep Qt/Boost etc out of this application. (I may want to deploy on an embedded system)
I guess main could poll something like "bool requestingFrame()" in the socket class, but I think main has better things to do.
Last edited by John Erlandsson; 04-18-2012 at 04:28 AM.
O_o
Yes. I did misunderstand slightly on which side of the logic the "socket" was operating.
Now then, if you like the "Qt" system, go ahead and do it that way. It is only a variation on the "Visitor" pattern that seems to have a lot of ugliness because "Qt" is built for the wide world which unfortunately needs lots of ugly hacks.
If `main' has something to do, you would need to spawn a new thread for `main' work and associate a bit of state with that new thread, the image chain thread, and the socket thread. These things could then communicate directly with each other by watching and signaling using relevant class methods where `main' is just chilling until everybody signals a complete state.
*shrug*
Because this is an embedded system, you'll have to hope you have something that supports conditional variables or events of some kind.
That said, I'm thinking that this isn't the best approach. It means adding new state, methods, and threads to the existing design while also developing a visitor chain to handle the signals. However, if you yield the socket and filter chain threads to some other primary thread (`main') by waiting on conditions or events (signal) when they are done with a work unit you can develop a fairly simple system where the primary thread issues new commands by triggering a signal. So, for example, your `main' function would not poll a function of the socket but would wait for a "I'm done with the old frame." signal from the socket and when appropriate would issue a "You have more work to do, socket." signal.
Soma
>> What I need is a way for the socket thread class to tell main that it needs a fresh frame from the pipeline.
From the end of the pipeline I assume. Where do frames go once they exit the pipeline now?
Before the current frame is "thrown away" and moves on to the next one, the code could check if an external party is requesting a frame and hand it off then. Or all processed frames could go to die in a circular buffer, and 3rd parties can tap that for a recent frame.
gg
Youre both right! No need to complicate things.
I just looked at the problem and thought signal/slot. But the "go to die in a circular buffer" approach is awsome!
Thank you!
//John
It is. Variations on the theme come up regularly with threaded code. Perhaps reach for it by default in the future instead of signals and slots.But the "go to die in a circular buffer" approach is awsome!
Soma
