New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add getWorkerTask functions #601

Merged
merged 1 commit into from Apr 12, 2014

Conversation

Projects
None yet
4 participants
@lultimouomo
Contributor

lultimouomo commented Mar 28, 2014

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

Signed-off-by: Luca Niccoli lultimouomo@gmail.com

@lultimouomo

This comment has been minimized.

Show comment
Hide comment
@lultimouomo

lultimouomo Mar 28, 2014

Contributor

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?

Contributor

lultimouomo commented Mar 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Mar 28, 2014

Contributor

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 =)

Contributor

etcimon commented Mar 28, 2014

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 =)

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

Signed-off-by: Luca Niccoli <lultimouomo@gmail.com>
@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Apr 2, 2014

Member

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?

Member

s-ludwig commented Apr 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@lultimouomo

lultimouomo Apr 4, 2014

Contributor

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?

Contributor

lultimouomo commented Apr 4, 2014

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?

Task caller = Task.getThis();
runWorkerTask_unsafe({
PrivateTask callee = Task.getThis();
caller.prioritySend(callee);

This comment has been minimized.

@MartinNowak

MartinNowak Apr 6, 2014

Contributor

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.

@MartinNowak

MartinNowak Apr 6, 2014

Contributor

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.

This comment has been minimized.

@s-ludwig

s-ludwig Apr 6, 2014

Member

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?

@s-ludwig

s-ludwig Apr 6, 2014

Member

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?

This comment has been minimized.

@lultimouomo

lultimouomo Apr 6, 2014

Contributor

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.

@lultimouomo

lultimouomo Apr 6, 2014

Contributor

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.

This comment has been minimized.

@MartinNowak

MartinNowak Apr 6, 2014

Contributor

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

@MartinNowak

MartinNowak Apr 6, 2014

Contributor

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

@MartinNowak

This comment has been minimized.

Show comment
Hide comment
@MartinNowak

MartinNowak Apr 6, 2014

Contributor

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

Contributor

MartinNowak commented Apr 6, 2014

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

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Apr 12, 2014

Member

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.

Member

s-ludwig commented Apr 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Apr 12, 2014

Contributor

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

Contributor

etcimon commented Apr 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Apr 12, 2014

Member

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.

Member

s-ludwig commented Apr 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Apr 12, 2014

Contributor

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)

Contributor

etcimon commented Apr 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Apr 12, 2014

Member

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);
}
Member

s-ludwig commented Apr 12, 2014

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);
}

s-ludwig added a commit that referenced this pull request Apr 12, 2014

@s-ludwig s-ludwig merged commit a5eee15 into vibe-d:master Apr 12, 2014

1 check passed

default The Travis CI build passed
Details

@lultimouomo lultimouomo deleted the lultimouomo:getWorkerTask branch Dec 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment