buffered rednet?

Title: buffered rednet?

Hi, I'm wondering if it's possible to buffer incoming rednet messages. As it is, incoming messages are dropped when not in a receive() call. This makes it impossible, as far as I can tell, to write a reliable listen server. The event API has the same issue. Calling os.queueEvent() doesn't actually queue the event, it just drops it immediately, so I don't understand what use it is. Maybe I'm missing something?

Thanks, loving CC!
- last

Events of any type are only eaten if you call a function that waits for a specific types of events before returning. These functions are: sleep(), which waits for timer events only; rednet.receive(), which waits for rednet events; read(), which waits for key and char events; and most turtle commands, which wait for a special turtle event you normally never even see.

If you must call one of those functions, you'll need to use coroutines, which there are threads in the tutorial section about (link). If you can avoid using any of those, then a loop calling os.pullEvent() at the top will never miss any events; there's a tutorial thread about os.pullEvent and how to use it effectively as well (link).

GopherAtl, on 07 February 2013 - 06:35 AM said:

Events of any type are only eaten if you call a function that waits for a specific types of events before returning. These functions are: sleep(), which waits for timer events only; rednet.receive(), which waits for rednet events; read(), which waits for key and char events; and most turtle commands, which wait for a special turtle event you normally never even see.

If you must call one of those functions, you'll need to use coroutines, which there are threads in the tutorial section about (link). If you can avoid using any of those, then a loop calling os.pullEvent() at the top will never miss any events; there's a tutorial thread about os.pullEvent and how to use it effectively as well (link).

Aha, I get it now. I was calling sleep() to test if events were buffered and didn't realize that sleep() was eating the events. I may add notes to the wiki for the functions that eat events, explaining all this.

So, if I call one of these event blocking functions in a coroutine, does it yield? What happens if I call coroutine.resume() on a coroutine that is waiting for an event?

When I call parallel.waitForAny() on two functions, what happens to the function that doesn't return first? Does it just get interrupted and killed?

Thanks for your help!

Anything that waits for an event (which all of the event-eating calls are doing) is a wrapper around coroutine.yield. Events are parameters passed through the coroutine.resume. Only one coroutine is ever running, so any coroutines called with a parallel.waitForAny are killed when any coroutine's status becomes "dead".