Coroutine.yieldwait(thread)

This doesn’t exist in vanilla LUA and would have to be implemented by ROBLOX directly.
This would yield the current thread until the specified coroutine function is resumed by a separate thread.

It would turn this code:

local c
local function Wait()
	local bindable = Instance.new("BindableEvent")
	local args
	local function x(...)
		args = {...}
		bindable:Fire()
	end
	c = x -- simulates adding x to the table of Waits to call when an event occurs
	
	bindable.Event:Wait()
	return unpack(args)
end


spawn(function()
	local secret = Wait()
	print(secret)
end)
wait(2)
coroutine.resume(coroutine.create(c),"hi")

Into this:

local event = coroutine.create(function()
    return select(2,coroutine.yield())
end)
spawn(function()
	coroutine.resume(event)
	--later on
	local secret = coroutine.yieldwait(event)
	print(secret)
end)

--to fire
wait(2)
coroutine.resume(event,"hi")
2 Likes

Wouldn’t this work: Documentation - Roblox Creator Hub As this allows pseudo-thread sleep until the Signal is fired?

The only way you could make one via script was using the RbxUtility library, which was deprecated and deleted recently (including the LoadLibrary function).

Unless you are referring to using a BindableEvent?

Your code could be simplified to the following in order to function in vanilla Lua.

local t
local function Wait()
  local t = coroutine.running()
  return coroutine.yield()
end

spawn(function ()
   local secret = Wait()
   print(secret)
end)

wait(2)
coroutine.resume(t, "Hi")

Unfortunately, the Roblox scheduler will attempt to resume certain threads automatically. As such yield behaves as wait in many places. I spent some time during summer looking at just this problem, I believe I found the problem and implemented a fix but somebody else would need to take this further.

3 Likes

This feature request makes a lot of sense, but I instead decided to design my game in a functional signal-based way that avoids yielding and spawn/coroutine.wrap all-together. You might want to try the same thing. If delays are needed I use a custom scheduler.

I haven’t had any issues thus far with this. Upon creation of a new thread and coroutine.yield()ng in it, the thread will yield appropriately and with a reference to it via coroutine.running I can resume it fine.

EDIT: On a side note, coroutine.kill(thread) would be great!

coroutine.yield being broken was intentional? There’s no way to yield for other threads without yielding for the next frame now. Why would anyone want coroutine.yield to behave exactly like wait()?

3 Likes

I’m not entirely sure which I why I was looking into it; @zeuxcg might better be suited to answer this.

Here’s the thread I posted about that last month

>_<

A useful feature was removed because it didn’t match documentation. Why not just update documentation?

coroutine.yield pushing the thread to the back of the stack is important for timing certain things. For example if the parent of an object changes and you want to immediately change it to something else, you now have to wait an arbitrarily long amount of time (however long a frame takes) before you can perform that action. With coroutine.yield in working order, that operation is simple and easy to perform in a single frame.

Generally, I want full control over what order my code is executing in. With a broken coroutine.yield, my only option for performing operations like that is to just toss the thread onto the next frame, where it gets executed in whatever order roblox decides on. The less control I have, the more problems appear due to unknown behavior within the engine, and the more time I have to spend diagnosing and working around these problems. In this case, there isn’t a workaround at all.

3 Likes

Oh, I wasn’t aware that RbxUtility was deprecated. It would be intresting if ROBLOX allowed for custom Signal creation, as Signals are pretty useful in general.

1 Like

Yeah, although that might be (hopefully) a sign of better things coming in the future. We’ll have to wait on that one.

I’m normally against ROBLOX modifying vanilla Lua functions and the same is true for this feature request. I think that fixing the behaviour described by @woot3 is a far better fix than introducing a new function.

Something I just realized:
wait(2^127) would act exactly like this (you can resume the thread as though that paused it - and to get the current thread you would just use coroutine.running())

Example usage to create an event:

local args
local create = coroutine.create
local resume = coroutine.resume
local unpack = unpack
local huge = 2^127
local thread

local function Fire(...)
	args = {...}
	resume(thread)
end

local function Wait(timeout)
	thread = coroutine.running()
	wait(timeout or huge)
	
	if args then
		return unpack(args)
	end
end

spawn(function()
	wait(1)
	-- fire thread after 5 seconds
	Fire("hi","after 5 seconds")
end)

wait(0.1)
print("hi","before wait")
print(Wait())

Issue is when the wait() finishes running, it will throw an error if the thread has been resumed (signal fired)
I don’t think it matters, but does anyone know a way to avoid it?

You’re going to run into some serious bugs doing this.

local t = coroutine.create(function ()
  wait(2)
  print(coroutine.yield())
end)

coroutine.resume(t)
coroutine.resume(t)

wait(2) will be resumed by the second call to coroutine.resume and then the call to coroutine.yield will be resumed ~2 seconds later by the Roblox scheduler. I advise against this completely if you can’t ensure the wait time is longer than the expected lifetime of the thread.

I don’t think what you’re saying is true because wait() only works in roblox threads - where coroutine.yield() doesn’t (and acts as wait()) - and it will also convert all threads it is in to roblox threads (so your coroutine.create() will be converted to a roblox thread - and hence coroutine.yield() will act as a wait())

But yea wait can definitely be unreliable if you’re working in coroutines and will need to yield later. However, for my use case it satisfies it (trying to make my own RBXScriptSignal).

Edit:

local args
local create = coroutine.create
local resume = coroutine.resume
local unpack = unpack
local huge = 2^127
local thread

local function Fire(...)
	args = {...}
	resume(thread)
end

local function Wait(timeout)
	thread = coroutine.running()
	wait(timeout or huge)
	
	if args then
		return unpack(args)
	end
end

spawn(function()
	wait(2)
	-- fire thread after 5 seconds
	Fire("hi","after 5 seconds")
	wait(3)
	print("yayyayay")
	Fire("hi","after 5 seconds")
end)

wait(0.1)
print("hi","before wait")
print(Wait(3))
print(Wait())

Just discovered this (not sure if it was what you were saying and I just misinterpreted), but it turns out that past waits will mess up future ones.

This thread discusses possible motivations behind the change, and potential issues with assuming how the scheduler is implemented:

I would appreciate it if you tested my code before assuming what it does in future.

Calling wait inside of a coroutine will add it to the list of yielded threads in the roblox scheduler, after the time has elapsed the thread will be resumed. Upon its next yield the scheduler will review the reason for the yield and make a decision. Specifically in the case of coroutine.yield the scheduler will add it to the list of waiting threads with the duration for resume being the minimum wait time.

The code I have given you will indeed be added to the roblox scheduler. The scheduler however won’t see the second call to coroutine.yield since this happens before the 2 seconds elapse, all it knows is that the thread is yielded and needs to resume after 2 seconds.

I am suggesting that the error you are seeing, you won’t always see. In some cases it’ll actually resume another yield.

It’s not ideal to shove undead threads into thread scheduler forever though; they won’t get garbage collected and may result in memleaks (esp since they may contain a large stack).

1 Like

I did try this code, I got confused by the fact that you were using wait() in a coroutine and then yield after - something that doesn’t work (it produces the same results as just having one resume):

local t = coroutine.create(function ()
  wait(2)
  print(coroutine.yield())
end)

coroutine.resume(t)
--coroutine.resume(t)

But I think I understand what you’re saying now.

Also @Shining_Diamando, this is a stack of size 100 with 10,000 different yielded wait threads concurrently and I don’t lag at all:

local resume = coroutine.resume
local create = coroutine.create
local huge = 2^127
local wait = wait

local function makeStack(x)
	x = x or 1
	if x > 100 then
		local thread = create(function()
			wait(huge)
		end)
		resume(thread)
		resume(thread)
	else
		makeStack(x+1)
	end
end

for _=1,10000 do
	makeStack()
end

You can try changing the numbers and it will still work (there’s only an initial delay of actually creating everything in 1 frame / however ROBLOX does it (idk))