Re: Separating protocols from I/O
- From: Cosmin Apreutesei <cosmin.apreutesei@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 24 Aug 2015 16:51:26 +0300
Have two coroutines that try and read from the same socket => who will get
the data?
The protocol should not care about coroutines. The provided read() and
write() functions can yield to the scheduler as needed, the protocol
doesn't have to know anything about that -- it uses them as blocking
functions. This is why coroutines are powerful because they allow
communication between the scheduler and the I/O functions without the
protocol layer even noticing that such communication it's occurring.
IOW, they allow the separation of protocols from I/O.
It was that.
What are you asking for if not documentation of how to duck type a
socket for a given library?
- designing the library around a simple I/O API rather than a
specific I/O library
- documentation on what your protocol needs out of an I/O library
(not just say "gimme a cqueues API")
- publishing the library without an I/O implementation
- state on your website that you dig the "do only one thing and do it
well" philosophy and that you want this to be the http library to rule
them all and not yet-another-http library :)
Other related posts:
