Re: port threadsafety redux

[David Pirotte <david@altosw.be>]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Hi Andy,

> ...
> This change fixed the crashes I was seeing, but it slows down port
> operations.  For an intel chip from a couple years ago the slowdown was
> something on the order of 3x, for a tight putchar() loop; for Loongson
> it could be as bad as 26x.  Mark was unhappy with this.

I agree with Mark here, especially because it slows down port operation even for
single threaded code.

>   But there are situations where this is not enough and there are also
>   situations where this is not wanted...

Indeed.

> One possible alternate solution would be to expose ports more to Scheme
> and so to make it easier and safer for Scheme to manipulate port data.
> This would also make it possible to implement coroutines in Scheme that
> yield when IO would block.

Not only does it sounds the best approach, but I can't see drawbacks, is there any?
I am in favor of this solution: in the end, only the user knows, and the way Mark
resumed this in his email is perfect [the last 3 paragraphs]

> Or, we could just make stdio/stderr be locked by default, and some other
> things not.  Seems squirrely to me though.

I would not do that, even for these ports, I'd leave them under the user
locking responsiblity.

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]