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.

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/

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?

18.01.2018 08:45, Andres Clari пишет:
> 
> 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?

asserts are disabled in release mode, so you have no it. Better would be say it seems to be working in release mode.

On Thursday, 18 January 2018 at 10:03:57 UTC, drug wrote:
> 18.01.2018 08:45, Andres Clari пишет:
>> 
>> 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?
>
> asserts are disabled in release mode, so you have no it. Better would be say it seems to be working in release mode.

Ahh, that explains it. Indeed.
Well I won't complain for now as it seems to be allowing me to do what I meant to do.

:)