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
orstop
that timer from a worker task or manually spawned thread.This is due to a
debug assert
inlibevent2
driver:debug assert(m_ownerThread is () @trusted { return Thread.getThis(); } ());
(eg. In
core/vibe/core/drivers/libevent2.d:483
for version0.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
andstop
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 overstd.concurrency.receive
, and then
send messages to thatTask
'sTid
to trigger therearm
/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.