On Tue, 25 Mar 2014 16:42:29 GMT, Luca Niccoli wrote:
Hi,
is there a way to communicate with a task that is spawned in a working thread with runWorkerTask()?
In general, is there a way to send messages to a task running in a different event loop?
Since runWorkerTask does not return a Task object I cannot use send/receive, and I cannot pass an explicit MessageQueue as an argument to the function since it is not isolated.I also tried doing something like:
ManualEvent e = createManualEvent(); runWorkerTask(function void(ManualEvent e) { scope (exit) e.emit(); // do something synchronous }, e); e.wait();
What should work is passing the Task
handle like this:
void workerTaskFunc(Task caller)
{
caller.send(Task.getThis());
}
runWorkerTask(&caller, Task.getThis());
auto task = receiveOnly!Task();
I'm not 100% sure if there isn't currently something that fails here, but in theory message passing between different threads/event loops should work fine. Maybe it makes sense to add a second form of runWorkerTask
that actually waits and returns the handle. Currently this isn't done for performance reasons.
But compilation fails with the rather unhelpful message.
Running dmd... FAIL ../../vibe.d/.dub/build/libevent-debug-linux.posix-x86_64-dmd-AB0707232CA963B5DA23C2232BBED51B vibe-d staticLibrary Error executing command build: DMD compile run failed with exit code -9
Looks like a DMD bug. Can you file a quick bug report at http://https://d.puremagic.com/issues/enter_bug.cgi? When I get some time, I'd try to make a reduced test case.
and still, it would allow me just to wait for the worker task to finish, not to retrieve data from it.
Am I missing something?
Something like this for instance would be helpful in ThreadedFileStream, not to block the main event loop when doing file I/O.
This is indeed something that is missing and planned since the beginning (hence the "Threaded" in the name). I wasn't sure about the best approach, though. Probably using a separate thread pool with 1-3 threads just for ThreadedFileStream
will be the best compromise, I guess.