If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Boost library thread callbacks

Hello,

I am looking for advise on how to accomplish something using boost thread algorithms.

Scenario: We have created an Firefox extension that must run on windows and eventually the Mac. We have created a C++ library (DLL for windows soon to be a library on the Mac) that implements a lengthy procedure that must call back to a JavaScript function in the extension codebase. We have tested the callback and it can be called in the main thread of the DLL. However calling the function from a worker thread will result in an unhandled exception being thrown. The exception is thrown because the function in not called in the same thread context as the library main thread. For all practical purposes the JavaScript callback does not support a multithreaded environment.

We have tried many different things (binding) to try to get the callback to be called from the main thread…but all attempts fail. I have thought about solutions for windows that may work by utilizing PostThreadMessage, but we really want a solution that will work on all operating systems.

I have seen a lot about boost::asio, but I cannot figure out how to implement this in a DLL in an asynchronous manner.

Re: Boost library thread callbacks

I cannot say how it works on OSX, but in Windows a DLL has no notion of "main thread", it's the loading process that controls in which thread the invoked dll procedures are called. Now, is the callback invoked synchronously ( like, say, you are using multiple threads to compute some value to be passed synchronously to the calling process ) or asynchronoulsy ( the called procedure is expected to return control to the extension immediately ) ?

Re: Boost library thread callbacks

We are passing a JavaScript callback to the DLL. I start a thread to compute some values. When the computation is complete I want to call the JavaScript callback. So the issue is calling the callback in the context of the main thread.

Re: Boost library thread callbacks

Sorry for the brief description. It a Firefox javascript extension. We call a method in the C++ DLL (from javascript) to do a long procedure. The method creates a thread to accomplish the task and the method returns to firefox as a non-blocking function call. In the method call we also receive a js-ctypes callback pointer that is saved as a global variable in the C DLL. That callback variable will be executed after the thread is finished. Since the JS callback is single threaded (ff extension thread) we cannot call the callback from the thread we generated. So we have to execute the callback in the context of the Firefox thread. So how can I call the JS callback from the thread that we created in the context of the Firefox extension thread. I have experimented with binding in the boost thread, but the function is still not executed in the context of the Firefox extension. So my question is how can I get the DLL generated thread to call the callback in the context of the thread that the DLL was loaded in.

Re: Boost library thread callbacks

>> We call a method in the C++ DLL (from javascript) to do a long procedure.
>> ... and the method returns to firefox as a non-blocking function call.
It sounds like you'll have to make a 2nd, blocking call into the DLL in order to "collect" the results. Unless you can somehow tell the extension system (from your thread): "hey, call me again because I have something for you".

Re: Boost library thread callbacks

an easy solution could be to create a worker thread in js via firefox's web workers instead. Your dll could still have its own thread pool, but using the firefox worker thread as a synchronous hub that in turn would manage the asynchronous comunication with the js code runnnig in the main thread.

Alternatively, you could use a more powerful api for writing the c++ binary, like XPCOM, supporting more general IPC natively. Probably, this would be the best way in the long run.