www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Vibe-d issue with timer in separate thread on debug builds

reply Andres Clari <andres steelcode.net> writes:
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.
Jan 10 2018
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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/
Jan 16 2018
parent reply Andres Clari <andres steelcode.net> writes:
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?
Jan 17 2018
parent reply drug <drug2004 bk.ru> writes:
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.
Jan 18 2018
parent Andres Clari <andres steelcode.net> writes:
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.

:)
Jan 18 2018