Uh no? They are still in serialized thread. They have still the behaviour of old spawn and delay functions minus the throttling part and they use Heartbeat internally instead.
1 Like
Is RunService.PreAnimation going to be the Missing event between Inbound Replication and Humanoids & Animations?
I just got around to trying to convert my code from FastSpawn to task.spawn
As it stands, the typings of task.spawn makes is near-unusuable without ugly-looking code. Why?
Well… currently the following code yields two script analysis warnings:
--!strict
task.spawn(function()
print('Hello, World!')
end)
This typing is bad because it assumes that the argument you pass into task.spawn has to return something. So at very least the any being returned should be optional.
The following monkey code with modified typing works:
--!strict
local task_spawn = task.spawn :: (((any) -> any?) | thread) -> any
task_spawn(function()
print('Hello, World!')
end)
That’s one problem solved—however, the argument(s) passed into task.spawn are also not variadic or optional. So you always have to pass a second argument to the task.spawn… even if you don’t want to
--!strict
task.spawn(function()
print('Hello, World!')
end :: any)
You could pass nil here, however this does affect the tuple size.
This is currently the way I am using task.spawn, and it’s super ugly:
--!strict
(task.spawn :: any)(function()
print('Hello, World!')
end)
HOWEVER, if I have anything before that line, I need to prepend the spawn line, or append the previous line, with a semicolon to avoid a syntax error:
--!strict
print("Hello?")
;(task.spawn :: any)(function()
print('Hello, World!')
end)
--!strict
print("Hello?");
(task.spawn :: any)(function()
print('Hello, World!')
end)
Please see if you can fix these typings. I’m stuck with some really ugly looking code.
4 Likes
task.wait() in a while loop never stops if the script is disabled or destroyed. This is similar to custom wait modules that use coroutine.yield. So I assume task.wait has a similar implementation but internally.
Reproduction:
while true do
print("Running")
task.wait(0.5)
end
Put this in a script, then disable the script. It will continue to print.
Now change task.wait to wait, then disable the script. It will stop.
With custom wait modules there was no way other than adding checks within the loop to fix this, but since this implementation is internal there should be a way to fix this. I hope it is fixed soon, it is the only thing preventing me from using task.wait and I cannot stand the original wait function much longer. So please fix this.
2 Likes
Oh i didn’t known.
But I don’t think inventing a new function just for different debugging is good and I think we should rather port the behavior of task.spawn to coroutine.wrap
I understand task.wait() vs wait() but is there a difference between task.wait(20) vs wait(20)? Should wait(x) be avoided at all costs now?
wait(x) bad
task.wait(x) good
Yeah basically task.wait(x) is a better wait. Though you should still remember to use event based coding when you can.
But you should replace spawn() with coroutine.wrap and delay with task.delay, wait with task.wait etc.
2 Likes
The second result is seldom used, so most people are probably unaware of it. It is very similar to the result of elapsedTime, which has nothing to do with the wait function. The wait function returning 2 values is weird, it doesn’t make sense to follow the same weird design set by wait.
See my reply here → Task.wait() does not respect script.Disabled and always resumes - #4 by WallsAreForClimbing
You should use the new methods. Here’s a quick cheat-sheet:
| Before | Now | Now (Alt.) |
|---|---|---|
wait() |
task.wait() |
|
wait(n) |
task.wait(n) |
|
spawn(f) |
task.defer(f) |
task.delay(0, f) |
delay(n, f) |
task.delay(n, f) |
|
spawn(function () f(uv1, ...) end) |
task.defer(f, uv1, ...) |
task.delay(0, f, uv1, ...) |
delay(n, function () f(uv1, ...) end) |
task.delay(n, f, uv1, ...) |
19 Likes
I forgot, does this do any performance increase with delay and spawn when switiching to task.delay/task.defer?
1 Like
Of course.
The new task library uses an improved polling system.
1 Like
I had a question.
Is wait() really deprecated?
Since then, I’ll change all my waits’ now. Else I’ll replace them later with task.wait
1 Like
It’s not deprecated yet so that people have some time to naturally migrate off of it before being annoyed by warnings in the script editor, but it will be at some point.
3 Likes
Well it does make sense, since wait is the only function that is used the most, so I guess it’s good to give developers some time. Thanks for the reply!
1 Like
I think there’s a small bug with the autocomplete, as the script editor says task.wait() returns void (nil)
The DevHub says it returns a number:
Is that intentional?
1 Like
So does this mean that my analogy is correct? When .defer was released I went by saying “It basically schedules threads to be resumed once there’s no other threads running anymore.” Would that mean that this analogy isn’t actually that wrong?
2 Likes
Almost, but not quite. A deferred thread is resumed when all threads that were scheduled or running when it was deferred have yielded or terminated.
5 Likes
I’ve heard before that Debris uses the older ‘deprecated’ wait/delay, anything I ask forward is dependant if that’s the case, if that’s the case, any plan to switch Debris to use task.wait/delay instead? Is that something that you guys think could break some code? If so, would Debris get possibly deprecated in the near future?
4 Likes
you can do this if you want:
local function Debris(waitTime, Instance)
task.delay(waitTime, function()
Instance:Destroy()
end)
end
2 Likes