Add getWorkerTask functions

[lultimouomo]

They provide a way to easily create a task in a worker thread and get a handle to it.

Signed-off-by: Luca Niccoli [email protected]

[lultimouomo]

The unittest blocks check only that the code compiles, but it seems to be what the other tests do.
Is there a way to actually run the tests in an event loop?

[etcimon]

Is there a way to actually run the tests in an event loop?

You could make a small project in examples/ or tests/ that demonstrates its usage (I like benchmarks best) and runs with the event loop. I think there should be a benchmarks/ subfolder for benchmarks with these tests that compares heavy i/o or heavy compute routines with runTask =)

[s-ludwig]

Thanks! Looks good as far as I can see. The only thing that could be improved is the actual name of the functions - "get" kind of implies that no real action is taken. I don't have a really good idea, though, runWorkerTaskRet or runWorkerTaskWithHandle would be possibilities.. other ideas?

[lultimouomo]

startWorkerTask maybe? Since the function waits until the worker task is started...
Or what about using an overload of runWorkerTask that takes an out Task parameter?

[MartinNowak]

You send the Task as first message with priority, so it will be the first one that is received and
you don't need to use a Typedef, receive((Task t) { result = t; }); should work just as well.

[s-ludwig]

Except if someone else priority-sent something that hasn't yet been received before calling getWorkerTask. Because it could come from any thread, it would at least be a race condition. Or am I missing something?

[lultimouomo]

As Ludwig said, the typedef is necessary because the caller task could receive a Task message at any moment before the callee task is even started. This could happen even without threads: the caller task creates the worker delegate and passes it to runWorkerTask_unsafe, than sits waiting for a Task message; a different task sends (even without priority) a Task message before the worker delegate has been popped from the worker queue; the caller task receives it and mistakes it for the callee task.

[MartinNowak]

Ah right, I forgot that it's receive not receiveFrom.

[MartinNowak]

How about spawnTask, IMO the semantics are close enough to spawn.

[s-ludwig]

I'd say spawnTask is a bit too ambiguous with the existing runTask and runWorkerTask (although spawn and spawnWorker would have been nice alternative names). I think I'll merge the pull request with the current name for now, since everything is technically sound, and open a ticket for finding an alternative name before the next release.

[etcimon]

Would it be preferable to encapsulate the delegate and arguments with a run() method? You could then give it a name like WorkerTask or ThreadLocalTask

[s-ludwig]

Which delegate do you mean (line number)? Using different types for thread local tasks or worker task doesn't buy much, though, because even thread local task handles can be safely passed to other threads, so that there is no real semantic difference between the two.

[etcimon]

Which delegate do you mean (line number)? Using different types for thread local tasks or worker task doesn't buy much, though, because even thread local task handles can be safely passed to other threads, so that there is no real semantic difference between the two.

for example runWorkerTask(&del, arg, arg2, arg3); could be

class WorkerTask(Args...) : LazyWorkerTask { void delegate(Args) del; m_args...; void run(); }

I don't see any practicality in anything vibe currently has, but suppose there would be lazy multi-threading routines, like multi-thread timers or multi-thread queues, having this kind of object handy would help make the API more convenient (I think)

[s-ludwig]

Can't you just call runTask(&WorkerTask(...).run) in that case (sorry I still can't imagine the use case you have in mind, so this may not make sense). But generally that overload of runTask is just intended as an optimization to avoid implicitly allocating memory for a heap delegate:

class C {
    void fun(int x) {
        runTask({ doSomething(x); }); // allocates x on the heap
    }

    void fun(x) {
        runTask(&doSomething, x); // does not allocate
    }

    void doSomething(int x);
}