Hi,
I was just wondering what was behind the decision to integrate poco and not boost.
I’ve been working hard today on trying to link boost into my android project, but to no avail.
I want to do some multithreading work and I was thinking that doing it with boost threads will keep me as much forward compatible as I can in preparation for the move to c++11. But due to my epic failure, I may do it with poco threads instead (which I’m not that familiar with yet).
Tal
the android version in master is already c++11 compatible, indeed 0.8.4 is also compatible if you just add -std=c++11 to your config.make. that way you can use std::thread
Hi Arturo,
That’s nice to hear, but as my project is also iOS, I will need to have c++11 support in there also, and this is a painful issue in 0.84, marked to be resolved in 0.9, right?
The reason I haven’t brought up the iOS side in the original post, is because I managed to use boost from iOS by linking a precompiled version of it found here: https://github.com/danoli3/ofxiOSBoost.
And a related question - in your opinion - should I move to master branch? Or wait until it’s stabilized and 0.9 released?
Thanks,
Tal
Where do I add it in the file…? I tried a few locations, but I don’t think it’s working for me…
Tal
add a line with
PROJECT_CFLAGS=-std=c++11
Oh, I forgot the minus. Android seems to work, but naturally I wasn’t able to compile it on iOS using v0.84.
So I’m contemplating between moving to OF master branch or doing it with poco threads.
Or is there a quick and dirty xcode fix for c++11 that I missed??
Thanks,
Tal
I’m not sure exactly how you’ll be using threads, but if it’s a queue based or task-based system, you might consider taking a look at ofxTaskQueue. It uses Poco::Threads under the hood and in the OF context, does all cross thread event handling in the OF update() method, which makes GL interactions simpler as well as thread synchronization. It also sends progress events, etc.
Hi Tal,
@bakercp has a point … I am also using Poco::Threads directly and it is becoming harder and harder to to do cross event handling out of the box. It is too late now to move back 
maybe in the next project.
Are you suing Boost only for the threads or for algorithms as well?
Shlomo.
Thanks for the tip, @bakercp, I might check it out!
@bakercp, @PetaFemto - currently I’m not using boost for anything I’m at the very early stages of a new project and I’m still figuring out what I’m wanna use for what. I just chose OpenFrameworks as the graphics library a few weeks ago.
As for boost, I was thinking of using it for the smart pointers and for the threading, but perhaps it would have come in handy in some other unpredictable ways.
My first multi threaded related task is indeed task based, I wasn’t initially thinking of using any task queue infrastructure for this, but I may reconsider. I was planning to just use a plane ol’ synchronized std::queue to communicate tasks and results between the UI thread and the worker threads.
The thing is that when it comes to hard-core multithreading, I’m not aware yet of the difficulties in front of me. If you can enlighten me, or better yet - refer me to some good source of information about it, I would be much obliged.
Regarding ofEvents, Isn’t there a way to synchronize the handling of an event to a specific thread or something? If not, that sounds like a handy feature to add…
And after all that is said and done, anyone care to to answer the question in the subject? Does anyone know the reason, or was involved in the historical decision to integrate poco instead of boost?
Thanks in advance,
Tal
@PetaFemto, I’ve been reading a poco threads presentation here: http://pocoproject.org/slides/130-Threads.pdf and it was very enlightening. I learned that there are built-in facilities for task management, event handling, syncing and more. Have you been using them too? Or just the plane ol’ threads and doing the rest of the pipe lining on your own?
Tal
For the retrieval of JSON, from Google’s CSE, I am using the Task, TaskManager, TaskFinishedNotification and TP classes as follows:
The problems I have revolve mostly around UI to Poco:Task communication and vice versa, for instance, waiting for the threads to terminate while asynchronously notifying a UI window of this event.
What is it exactly that you are trying to achieve?
in the master branch there’s a new class ofxThreadChannel that allows for easy sinchronization between threads allowing to not use locks at all in most cases.
Actually, not a very different task than yours. Downloading multiple images at the same time from the web asynchronously, notifying the UI when images are downloaded so that they will be shown. I currently use ofxThreadedImageLoader, but I don’t seem to get notifications back from it. I was thinking of rewriting that part and stop using the add-on, and also take the opportunity to write it more robust (for example, currently I don’t know which image was downloaded, so I just refresh all).
I’m not sure I understand the problems you described. When threads are done running a task, why not write the result into a centralized data structure, and signal the UI thread with an event so it will read the data?
Tal
@arturo - very nice. I think I’ll finally gonna pull master and try running out of it. I guess the new class is intended to work specifically with ofThreads and not any poco thread?
Tal
The client loader example of ofxHTTP client uses ofxTaskQueue to do exactly what you want.
It even includes progress bars, control over the queue size, callbacks, etc.
https://github.com/bakercp/ofxHTTP/blob/master/example_basic_client_loader/src/ofApp.cpp#L37
Since ofxTaskQueue only emits its evens during the update loop, it’s easy to load images, textures, etc with the and you won’t have to worry about thread synchronization. Under the hood it uses Poco::Task and Poco::TaskManager. Each task (including the ofxHTTP client tasks, extend Poco::Task.
It’s well documented. Check it out.
it’s actually agnostic to the kind of threads you are using. it’s based on poco classes but the idea is to migrate it to c++11 once it’s supported on every platform