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.