Re: [dylan] Stream locking (was: Method combinations as a design pattern for locking)

On 12/18/2013 02:59 AM, Bruce Mitchener wrote:
> Ingo,
> 
> Part of the problem that you're having is that streams do locking
> internally now when they aren't supposed to do so.
> 
> The original design documents for streams indicate that they are
> unlocked by default and that the application code should use stream
> locks (via with-stream-locked or stream-lock/unlock directly) when the
> stream may be accessed by multiple threads.

I am specifically uncomfortable with the lack of a lock enforcement
option, not unlocked streams themselves. The latter make perfect sense
for both sequence- and thread-local file-streams, which would be most
frequent and should therefore dictate the default (unlocked).

But I still think we need a deterministic protocol enforcement option,
such as making the lock slot false-or(<lock>) and checking the lock,
if present. My reason for this is practical experience hunting down
these issues. They are non-obvious and impossible to identify without
expert knowledge.

> Unfortunately, a couple of years ago, some locks were introduced to the
> streams library and I suspect that that has led to some issues over
> time.  An example of that is that in the typical case of creating a
> <string-stream> for printing some data to it, we have to be sure that we
> create it unlocked (like in the date code in the system library),
> otherwise it can become a visible overhead when profiling.

You sum up the history of it well, I think.

> I'd like to see a return to streams being unlocked by default and
> applications which are threaded having to lock them as needed and as
> appropriate.  One place where this would cause an issue is printing to
> *standard-output*.  We can have format-out() do a with-stream-locked in
> that instance.

Making format-out (and force-out) into locking wrappers would be a
workable compromise for me.

> Thoughts?

>  - Bruce
> 
> 
> 
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers
> 
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers