[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: port threadsafety redux
From: |
David Pirotte |
Subject: |
Re: port threadsafety redux |
Date: |
Fri, 13 Feb 2015 16:35:36 -0200 |
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
pgp3oCMXgmt8f.pgp
Description: OpenPGP digital signature