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