Am 03.01.2018 um 00:16 schrieb Benjamin Schaaf:

On Tue, 2 Jan 2018 23:45:54 +0100, Sönke Ludwig wrote:

Am 02.01.2018 um 22:40 schrieb Benjamin Schaaf:

If I start a timer in a task on the main thread, say while handling a web request, I can't rearm or stop that timer from a worker task or manually spawned thread.

This is due to a debug assert in libevent2 driver: 

debug assert(m_ownerThread is () @trusted { return Thread.getThis(); } ());

(eg. In core/vibe/core/drivers/libevent2.d:483 for version 0.8.2)

From limited testing, my code seems to have no issues in release mode (ie. seemingly the only thing breaking my code are these debug checks).

Are rearm and stop not thread safe? Is the debug statement actually saving me from race conditions/data races, or could they be removed?

Except for ManualEvent and the derived synchronization primitives, all
entities are thread-exclusive. Using them from other threads can
sometimes lead to the wrong state being set (due to the use of some
global TLS variables) and will definitely create race conditions in the
event driver.

For this case, the simplest solution is probably to simply start a task
in the main thread that loops over std.concurrency.receive, and then
send messages to that Task's Tid to trigger the rearm/stop actions.

Thanks for your quick response! I was hoping to avoid doing something like that, but I guess for now I don't have much of a choice. I assume this also means some stuff (eg. Timers) will break if you turn on HTTPServerOption.distribute.

I think it would be greatly beneficial to have this thread safety stuff in the API docs for Timer, I'll have a look at submitting a pull request for that.

Right, HTTPServerOption.distribute is in the process pf being
deprecated for that reason. Using runWorkerTaskDist and initializing a
HTTP server in each worker task with HTTPServerOption.reusePort is the
new recommended way for in-process scaling across cores.

But the rest of the API has been adjusted to adhere to shared as far
as possible, so unless there are any casts in the code and only vibe.d
primitives are used to run things in threads, the compiler should make
sure that everything is thread-safe (std.concurrency and
core.thread.Thread for example don't to the proper checking for
example, so that needs some care).