Vibe-d issue with timer in separate thread on debug builds

Andres Clari andres at steelcode.net
Thu Jan 18 05:45:51 UTC 2018


On Tuesday, 16 January 2018 at 09:04:18 UTC, Sönke Ludwig wrote:
> Am 10.01.2018 um 15:40 schrieb Andres Clari:
>> Hi, I have an app that uses vibe tasks, fibers and timers 
>> extensively, and I found an issue only for debug builds, when 
>> canceling a timer. However the code in question works just 
>> fine in the release build.
>> 
>> But having this here makes testing certain things in my 
>> program a pain, since it'll crash on the assert in question:
>> 
>> vibe-d-0.8.2/vibe-d/core/vibe/core/drivers/libevent2.d:474
>> debug assert(m_ownerThread is () @trusted { return 
>> Thread.getThis(); } ());
>> 
>> 
>> Also, not sure I understand that assert properly... Is it 
>> checking the stop timer call is fired from the main thread the 
>> event loop is running? That would be bad, since basically that 
>> timer run from a child thread.
>
> The basic requirement for almost all vibe.d primitives is that 
> they may only be used within the same thread in which they were 
> created. Anything else requires message passing (e.g. using 
> std.concurrency) to issue the operation in the owner thread.
>
> There incidentally is a recent thread on the vibe.d forum on 
> this topic: 
> https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/48663/

I see, then although it works (or it may work) on release 
shouldn't that assert happen for release builds by default too? 
Or is the thought that you got the error running the debug build 
you should do it a different way on your own and skip the check 
all together?


More information about the Digitalmars-d-learn mailing list