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.