11–20 of 23 posts
Coroutines are also fantastic for scripting Game AI: local player = nil while(player == nil) do yeild(0) player = LookForPlayer(...) end while(WalkTowardsPlayer(player)) do yeild(0) end while(!PlayerDead(player)) do MeleePlayer(player) yield(0) end Makes state management super-simple and is something you can easily teach to designers as well. This is partly why you see Lua show up in so many game engines.
Coroutines are also fantastic for scripting Game AI: local player = nil while(player == nil) do yeild(0) player = LookForPlayer(...) end while(WalkTowardsPlayer(player)) do yeild(0) end while(!PlayerDead(player)) do MeleePlayer(player) yield(0) end Makes state management super-simple and is something you can easily teach to designers as well. This is partly why you see Lua show up in so many game engines.
FSM may be a better fit for this specific application, though.
However if you're working with designers who don't have a lot of formal education it's much easier to convey the concept of a function that "pauses" where yield() happens.
Also quite a bit of gameplay code ends up as throw-away so being able to quickly put behaviors together is a plus.
i'm using java fibers ( https://github.com/kilim/kilim ) for a database for anyone interested in using fibers inside a java webapp, i just wrote up a quick survey of async java servlet performance: http://blog.nqzero.com/2016/01/asynchronous-java-webserver-h... (based TechEmpower plaintext benchmark, but limited to java async) the model is that you use async in the server, and then bridge to a fiber implementation an…
One caveat with coroutines and fibers is that all the code that runs on them must be fully aware that they are running on said coroutines and fibers.
at least in java (i'm using https://github.com/kilim/kilim , but quasar appears to be similar), only methods that yield need to be aware
One caveat with coroutines and fibers is that all the code that runs on them must be fully aware that they are running on said coroutines and fibers.
I generally prefer coroutines myself but this article doesn't cover some points well. 'Fair scheduling' - nobody writes single threaded programs that process requests sequentially. It's either a thread-per-request system vs. a coroutine-per-request system. Threads are generally going to be more fair at scheduling since they are preemptive. Most coroutines are cooperative (Python, Lua) - so a long running coroutine (s…
I generally prefer coroutines myself but this article doesn't cover some points well. 'Fair scheduling' - nobody writes single threaded programs that process requests sequentially. It's either a thread-per-request system vs. a coroutine-per-request system. Threads are generally going to be more fair at scheduling since they are preemptive. Most coroutines are cooperative (Python, Lua) - so a long running coroutine (s…
Yes, fibers/coroutines are good for socket I/O because sockets could be made non-blocking, therefore a fiber could yield on EWOULDBLOCK error from a socket. For file I/O there is no non-blocking I/O option, so the whole OS-thread might block on it along with all the fibers that it owns. Therefore any operation that is not socket I/O and goes beyond CPU and RAM should be delegated from fibers to a good old worker thre…
i'm using java fibers ( https://github.com/kilim/kilim ) for a database for anyone interested in using fibers inside a java webapp, i just wrote up a quick survey of async java servlet performance: http://blog.nqzero.com/2016/01/asynchronous-java-webserver-h... (based TechEmpower plaintext benchmark, but limited to java async) the model is that you use async in the server, and then bridge to a fiber implementation an…
What do you think of Quasar fiber[1]? [1] http://docs.paralleluniverse.co/quasar/#fibers
Comsat (one of the servers in my benchmark i linked) is written by the same people and uses Quasar. so eg Comsat Jetty is an async jetty servlet with a bridge to a Quasar fiber-based handler. the performance in my simplistic test wasn't great (async jetty was 50% faster than comsat jetty) - i don't know if that's representative
however, it's very easy to work with and mimics the Jetty API, which is really nice. https://github.com/nqzero/jempower/blob/master/comsat/src/ma...
for my database i was initially worried about the LGPL license for Quasar, but the guys assured me that it's not viral in this usage and i think they're correct
pron (one of the developers) is active posting on HN and has written some very good/knowledgeable stuff about java, so i suspect that Quasar is technically solid. i do plan on doing an integration with my database at some point and i'll write up my results and post them on HN
Earlier quoted context omitted.
Yes, fibers/coroutines are good for socket I/O because sockets could be made non-blocking, therefore a fiber could yield on EWOULDBLOCK error from a socket. For file I/O there is no non-blocking I/O option, so the whole OS-thread might block on it along with all the fibers that it owns. Therefore any operation that is not socket I/O and goes beyond CPU and RAM should be delegated from fibers to a good old worker thre…
Well, there's no POSIX async file I/O, but there's libaio for Linux's aio syscalls (io_submit and co.), which works. (MySQL/InnoDB uses it for example.)