Martin Sustrik

It's actually the central tenet of libdill design: It tries to avoid both callbacks and state machines. Once you allow for partial reads or writes, you have to keep state...

Imagine implementing one of the socks5_connect functions so that they support non-destructive timeouts. When the timeout is reached you would have to save the current state of the protocol ("reading...

Yes, I think it's a slippery slope. Imagine a protocol that interleaves unstructured data with keepalives. From the outside point of view it would look like a regular bytestream protocol,...

I see, so it boils down to performance. Have you run any performance tests? Like, for example, comparing reading a lot of data byte-by-byte compared to reading it in 256...

That's quite a difference! I've been thinking of how to support this scenario within breaking the main principle behind libdill (no callbacks & no state machines). What it boils down...

Ok, another option is to provide a third interface (in addition to bsock and msock), something like "partial bytestream". This could be implemented by TCP and TLS protocols. It wouldn't...

Yes, that's the idea. We could have something like bbatch interface that would allow for partial reads/writes. The functions to call it (bbatchsend, bbatchrecv) could check whether the socket passed...

What's the point? If the parent coroutine waits for the child coroutine, it can as well do the work in normal synchronous function, no?

Look here for example: https://github.com/sustrik/libdill/blob/master/libdill.c#L39 It's implementation of msleep. It registers a timer and does dill_wait() to wait till it expires. In the meantime other coroutines are given a chance...

What do you mean?