Re: Stdio.Buffer.set_buffer_mode revisited

Stephen R. van den Berg wrote:
>Per Hedbor () @ Pike (-) importm?te f?r mailinglistan wrote:
>>| class Blocking( function(function(mixed:void),mixed...:void) async_func )

>>The main advantage of this is that there is no longer any need for a
>>single thread in the low-level code, and in fact, it works even if the

>I'll try and wrap my head around this and see if it helps me reduce/eliminate
>the threads in the pgsql driver.

Well, I looked at it, it is perfect for transformations from callback to
blocking and back.
However, in this case it would mean that:
a. Upon data arriving I'd have to wait and collect/assemble the network
   packets as they arrive until I have enough to decode.
b. This does incur overhead (a little) to check for a complete packet
   on every callback (luckily, this overhead is small in this case, since
   it mostly involves checking the first 5 bytes of the buffer; on other
   protocols it might be more involved and require more (repeated) parsing).
c. It increases latency because I can't start to process the message until
   it has arrived in full.  To increase parallelism with the database
   and reduce latency in general one would be better off using the time
   between network-packet arrivals to already process the arriving data.

Without a thread this is not really possible.  However, having said that,
it would be possible though (not sure if desirable, it would depend
on thread creation overhead) to only create the thread after the first
byte of a message has arrived, and then end the thread as soon as the whole
message has been processed.  This would reduce the number of threads
remaining to zero during idle periods with the database (currently I keep
one thread per filedescriptor in a blocking wait on the condition
in range_error()).
-- 
Stephen.