LOL, I already started using task library before you guys posted this!
Task library is insanely useful, thanks to whatever genius is out there who made this!
You mentioned that issue, however I’m not the most understanding when it comes to this stuff, does this mean that the one frame wait from using coroutine.resume on a Roblox spawned thread, is not a problem anymore when using task.spawn? That’s what I’m most excited for.
I realized today, before this post that task.desynchronize was available to use, and when used, didn’t throw an error. I assume Parallel Luau wasn’t added, as I didn’t include actors. Is this correct?
1 Like
I dont see the parralelism decumentation… Was it intention becauss its in beta?
2 Likes
I wonder, is it possible to simulate or directly create immediate mode signals with the task library or is that completely out of the question with deferred? I specifically mean Roblox events - for pure Luau custom signals it should be possible but not sure about Roblox ones.
Deferred signal mode will eventually become standard and we’ve currently been given a time extension before it becomes default due to the problems raised in the thread but I’m not particularly sure if there’s a way for us to be able to get immediate signals in deferred mode or not if we need them. It may look pretty ugly to constantly be using task.defer and probably bad for performance with the whole coroutines and anonymous functions business. I’m also not sure how fond I am of everything potentially running later to ensure my code is deferred signal-compliant.
Also, how does one reuse coroutines? What’s the benefit of doing so?
2 Likes
More than possible, I already wrote up a pure Lua Signal implementation with it!
The source code provides a nice demonstration of re-using a coroutine, and also using task.spawn in an interesting way to implement Signal:Wait().
11 Likes
i just have one question
will games created prior to the task library’s release get updated to contain the task library?
1 Like
Why does task.delay() with no args crash? You can literally use this to crash the client or server.
1 Like
Do you mean the following?
local thread = coroutine.running()
-- pass thread ref elsewhere
local result = coroutine.yield()
wait() -- this wait?
return result
If so, when resuming with task.spawn the wait call is no longer necessary.
1 Like
task.spawn runs the code inline as coroutine.wrap would. For deferred code you should use task.defer.
A fix is coming for this.
It allows you to replicate the behavior of fastSpawn when deferred events are disabled.
Do you mean when deferred events are enabled ?
No, when they are disabled.
When fastSpawn is implemented with a BindableEvent and deferred events are disabled the callback function is executed immediately. The new spawn method does the same irrespective of whether signaling behavior is set to deferred or immediate.
4 Likes
There is a problem that its very inaccurate the first few seconds when the game starts, it should be fixed.
1 Like
I don’t see how it would cause any issues.
When the game is starting using heartbeat would also be inaccurate because of the fps drop when everything is loading but it’s not really a problem. In an actual game it would all be behind a loading screen while the client is loading.
It’s a compatibility issue! If a game is relying upon the timing for wait to be one way, it’s not really fair to change it entirely.
what about behaviours like spawn, or delay?
Sorry to bother you again, if you were asked for an opnion, what would you say is better? Using this, or a solution like it, like CloneTrooper’s Thread, or using task.wait?
Any explanations as to why it’s made to behave this way, I can see this resulting in unexpected yield frequencies, especially for accurate things that need to be binded to 60 fps (because task.wait behaves in the way you stated on the server as well). So just wanting an explanation is all. Also to add to this task.wait can’t yield for a proper 60 fps step when doing task.wait(1/60) , seems to result in task.wait yielding for about 1/44, a pretty big drop.
2 Likes
Most performance heavy functions are ran in C closures, which means they are implemented in C/C++ to evade the Lua VM’s performance cost.
You can see if a function is a C closure by doing the following:
local func = print -- print is a c closure
print(debug.info(func, "s")) -- 's' for source, returns [C] because it's a C function
8 Likes