Wait, since internally the respective port does all the decoding logics anyhow, then the fact that Gambit internally signals IO events using mutex-based condvars should *not* affect the potential IO speed achievable, as the port internally could do read-ahead at the level of u8vector and the threadsafety-condvar stuff could work at that level;

Then, the read-u8:s could be made thread-unsafely without any need for condvars ever.

At least this understanding makes clear that independent of how Gambit's IO works internally, read-u8 and friends *can* be invoked completely without need by far for locking on a per-invocation basis, but rather once per block, so that would be once per 10240 calls or alike - very fair!. Though,

Only in case this could be done in such a way that it not interferes with hybrid binary & char access - that would be the only thing such a read-ahead mechanism could interfere with, wouldn't it? - it would be a 'complete' solution.

If you have any thoughts feel free to share.

Anyhow, for me the prios now are what's addressed by the parent email in this thread and points a) & b), as these are the things essential for driving realworld HTTP and HTTPS and alike reliably and cleanly.

Next thing after this would probably be c) & d) as to make the IO system abstract for this kind of uses. (As in, ability to implement protocol handlers for SSL etc. as Gambit ports in a way that delivers well.)

2013/3/11 Mikael

Hi Dimitris,

Thank you for your response.

Feel most free to send it to the Gambit ML too, as to encourage further conversation on this topic.

The IO performance can be boosted to really good performance by doing it via read/write-subu8vector only, but that has huge system-level limitations so even though for almost-all applications that can solve it, in the big picture it's not a solution.

Re boosting byte-level access speeds, I remember I think Marc making a ML post where he inlined read-char's or read-u8's code in the user code and got much higher performance that way. That saves of the trampoline call at least... It should be easy to repeat that experiment as to check out how it affects performance.

Condition variables... Hmm. Do you have any clue at what granularity they work?

Brgds :) Mikael

2013/3/10 Dimitris Vyzovitis <vyzo@hackzen.org>

+1

If I may add, point (f) should be a priority. i/o performance is
severely hampered by the constant mutex acquisitions.
At a first approximation, each individual write should stop writing
one character at a time (with a mutex lock each time).
Having full control of whether a mutex is used at all is even better,
as it is almost always the case that a single thread is
reading/writing a port (exceptions being the std ports). The problem
there is the way the i/o system i simplemented though, as the events
are tied to condition variables and these in turn tied to mutexes to
work reliably.

PS: I owe you some coroutines :)