[gambit-list] Your feedback would be much appreciated re: Proposal for enabling IO errors to be reported through returning of a custom value instead of by throwing exception, through DSL with exports: ##io-error-behavior param, ##default-io-error-behavior unique value, ##last-io-error param.

Mikael mikael.rcv at gmail.com
Sun Mar 10 22:33:55 EDT 2013

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

Brgds :) Mikael

2013/3/10 Dimitris Vyzovitis <vyzo at 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20130311/d0c197cc/attachment.html 

More information about the Gambit-list mailing list