Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
  • 0
Suterusu

Using Coroutine

Question

11 answers to this question

Recommended Posts

  • 0

I noticed on the wiki this part here:

 

Important: If you use event handling in driver mode, then event functions will be called from the environment of the OS event handler and variables local to your program will not be visible!

 

Do you have any code examples that use event.listen?

Link to post
Share on other sites
  • 0

So far I have ~450 lines... I am trying to write a "cell network" program to be able to send messages between nodes on a "tree" structure".  I have all the logic for "routing" messages, etc. the part I am trying to deal with is the psudo concurrency of trying to send/recieve.

 

Using event.listen() as a "background" listener has worked, sort of.  I've been able to send and echo back messages from computers connected to different cell towers over my network using hop-by-hop of nodes with modem.send().

 

What I am trying to do with event.listen() is this (calling a function directly instead of an event handler):

event.listen("modem_message", listen)
function listen(msg, localAddress, remoteAddress, port, distance, data)
	local payload = serialization.unserialize(data)
    --more code here
end

That works fine, I can do other "stuff" in code, and when an event type "modem_message" is received, it calls listen() and passes it all the parameters.

 

What I am stuck on however, is if another function wants to send, "modem.send()" to another host, the listen() function will recieve the reply.  I don't want to call event.pull() within the function that used modem.send() in order to "wait" for a reply back because it will block and prevent further code execution.

function nameLookup(name)
	local querry = {["type"] = "querry", ["name"] = name}
	sendData(querry, nameServer)
   --more code
end

function sendData(data, destination)
	local data = serialization.serialize(data) 
	local payload = {["dstAddress"] = destination, ["srcAddress"] = myAddress, ["data"] = data}
	m.send(rootPathList[1], 16, serialization.serialize({["msgType"] = "data", ["payload"] = payload}))
end

So, from within nameLookup() we should be getting the reply data there, the stuff listen() gets when called by event.listen(), so we can parse it and return the function to the calling function.

 

 

Link to post
Share on other sites
  • 0

Hmmm. That is a problem huh.. The first idea I have would actually involve coroutines like you suggested so sorry for not answering your initial question directly.. Didnt mean to make you go through hoops for help.. It seems like you need a call and response stack of some sort to manage connections. Here is what I know about coroutines in lua..

-- coroutines are made with functions like so
local co = coroutine.create( function() print( "doing stuff" ) end )
coroutine.resume( co ) --> "doing stuff"
coroutine.resume( co ) --> "error: cannot resume a dead coroutine" --shit..

--[[ basically the coroutine will only live as long as the function that it was created from still has code to execute.
The first call to resume ran the function and now the function doesnt have anything else to run because it essentially returned nil.
]]

--If you want a coroutine to constantly run then your function will have to do the same and handle that.

co = coroutine.create( function( ... ) 
    local var = { ... }[1] -- just to try some stuff with
    while true do
      print( "doing stuff" )
      var = var + 1
-- here we can send data back to the caller of the coroutine via coroutine.yield
-- also the caller can inject data back into to the coroutine with the subsequent call to resume
      var = coroutine.yield( var )
    end
end )

local var = coroutine.resume( co, 5 ) --> "doing stuff" var = 6 now..
print(var)
local var = coroutine.resume( co, var*2 ) --> "doing stuff" var = 13 now...

--[[The first time we resume a coroutine it will be passed the arguments and  all the subsequent calls to resume will fall into our loop and be "returned" via our call to yield. Keep in mind we can yield all we want in our function.]]

The lua PIL on coroutines has done a way better job of explaining this the I have. But the best thing you can do is just experiment with some really simple coroutines until you understand the potential of how powerful both resume and yield can be.

 

 

 

Link to post
Share on other sites
  • 0

Did you ever get this working? I'm trying to write a similar program. Rather, I'm trying to rewrite a program I wrote in Computer Craft that used coroutines to monitor redstone inputs and send them to a server, while updating outputs based on data from a server. Every way I try to implement it results in the computer eventually failing out for not yielding.

Link to post
Share on other sites
  • 0
3 hours ago, Ketzak said:

Did you ever get this working? I'm trying to write a similar program. Rather, I'm trying to rewrite a program I wrote in Computer Craft that used coroutines to monitor redstone inputs and send them to a server, while updating outputs based on data from a server. Every way I try to implement it results in the computer eventually failing out for not yielding.

Tis a really old post.. If you're seeking help on a particular piece of code try making a new topic in Programming/Support :)

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.