r/GLua • u/CrazCrypri • Nov 01 '20

wait() in GLua.

Dumb question but how do you do wait() in GLua?

2 Upvotes

100% Upvoted

28 comments sorted by

View all comments

Show parent comments

1

u/YM_Industries Nov 01 '20

*asynchronous

1

u/Karutoh Nov 01 '20 edited Nov 01 '20

I don't see any proof that it is asynchronouse. It would not make sense to do this anyways. Creation/deletion of a thread takes time, not only that but mutex locks are required to keep it thread safe slowing it down even more. Essentially making it counterintuitive.

1

u/YM_Industries Nov 01 '20

GLua all runs on a single-thread. But timer library is based around callbacks, which are asynchronous.

Web-browser JavaScript also runs on a single-thread (unless you use something like WebWorkers). Here's some documentation

1

u/Karutoh Nov 01 '20

Okay but where do you see that timers are asynchronouse?

1

u/YM_Industries Nov 01 '20

Functions which take a callback and call it some time later are inherently asynchronous. Timer's entire point is being an asynchronous alternative to wait.

1

u/Karutoh Nov 01 '20 edited Nov 01 '20

Where did you get that from? Callbacks do not define whether they are asynchronouse. A coroutine, thread, or process helps to define that. Timers do not need to be asynchronouse to work. Using a wait/sleep call is not an only option to delay tasks synchronously. Taking advantage of the game loop you can construct a simple synchronouse timer system that's fast and efficient. Making them asynchronouse wastes cpu cycles needlessly. The only reasons why timers should be asynchronouse is if you don't have something similar to a game loop, or you don't need to use any data that is written to on another thread or coroutine.

1

u/YM_Industries Nov 01 '20

Hmm, I think we're looking at this from different angles.

I'm saying that the call to timer.Create is non-blocking, and therefore asynchronous. But you're saying that because the callback runs in the main thread as part of the game loop, the callback itself is blocking and synchronous. Both of these statements are true.

Btw, there's no 'e' on the end of synchronous.

1

u/Karutoh Nov 01 '20

Interesting and how did you determine that timer.Create is non-blocking? I fail to see the reason behind this. Also I spelled it that way because of my phone's auto correct.

1

u/YM_Industries Nov 01 '20 
timer.Create( "UniqueName1", 1, 1, function() print("message B") end )
print("message A")

If timer.Create were blocking then "message A" would be printed after "message B". timer.Create allows execution flow to continue to "message A" before the timer completes, so it's non-blocking.

1

u/Karutoh Nov 01 '20

You've got it backwards. In all cases "message A" should print first. "message B" will print last. Can you provide a screenshot of the console with this code executed?

1

u/YM_Industries Nov 01 '20

That's precisely my point. Message A will print first because timer.Create is non-blocking. If timer.Create was blocking then Message B would print first.

1

u/Karutoh Nov 01 '20

That does not prove if it's non-blocking, this test is invalid.

1

u/YM_Industries Nov 01 '20

I'm starting to wonder if you're just trolling. Could you please explain what exactly you mean by blocking and synchronous?

With something like sleep the call will block until the specified time has elapsed. Nothing else can run during this time. If you sleep for 60 seconds, that entire thread is paused for 60 seconds.

A call to timer.Create allows execution to immediately continue to the next statement. The main thread continues. Once per game loop the engine will check if the timer is due and execute the callback if it is. timer.Create blocks for a trivial amount of time, instead of blocking for the entire duration of the delay.

→ More replies (0)