maria-developers team mailing list archive
Mailing list archive
Re: [Commits] Rev 3020: MWL#192: Non-blocking client API for libmysqlclient. in http://bazaar.launchpad.net/~maria-captains/maria/5.2
On Fri, Sep 23, 2011 at 4:32 AM, Kristian Nielsen
> MARK CALLAGHAN <mdcallag@xxxxxxxxx> writes:
>> Why does this need to save/restore thread contexts (setcontext, etc)?
>> I think that if the library is that hard to change then it should be
>> fixed or a simpler solution should be attempted.
> In general, when implementing non-blocking semantics like this, there are two
> main approaches:
> 1. Write the code in event-driven style. This means using some kind of state
> machine or message passing (or both) rather than normal nested
> calls. Whenever code needs to do I/O, or call another function that might
> do I/O, the current state is manually saved to some struct and control
> returns to the caller. When the I/O completes control must continue in the
> next state of the state machine or handler of completion message.
> 2. Use co-routines (also called fibers or light-weight threads or
> whatever). The code is written in normal style with nested calls. For
> operations that need to do I/O, a co-routine is spawned to run the
> operation; when waiting for I/O the co-routine is suspended, and resumed
> again when I/O completes.
> The main reason I choose (2) is similar to what RethinkDB describe here:
> Basically, (1) is nice for writing quick IRC bots and the like, but as the
> complexity of the problem grows, the event-driven code becomes very hard to
> maintain and extend.
> For adding non-blocking to an existing library like libmysql, there is the
> added advantage that the change can be much less intrusive, as we can avoid
> re-writing parts of the existing code into event-driven style.
Why isn't it sufficient to do a sequence of non-blocking reads to
buffer enough data to produce a query result and then process the
received data? That doesn't require getcontext/setcontext.