Re: [dylan] stream locking: opt-in or opt-out?

I think that, except in a very few cases such as stderr, multiple threads
writing to the same stream is at the least bad program design and probably
a bug.

I would make the default to be non-locked, but with detection and warning
of writing from multiple threads, if cheap to do. e.g. store and compare
the thread IDs or TLS pointers or something. Even the stack pointer would
suffice, if you can get the stack base and limit for the current thread
(only has to be one once per non-locking stream, the first time it's used).


On Thu, Aug 1, 2013 at 3:39 PM, Bruce Mitchener
<[email protected]>wrote:

> Currently, all streams default to having a lock and requiring that people
> opt out of being locked:
>
>   slot private-stream-lock-value :: false-or(<lock>) =
> make(<recursive-lock>),
>     init-keyword: stream-lock:;
>
> I think there is a reasonable case to be made that streams could or should
> default to being unlocked and allow people who know they need locking to
> opt into locking and give them an appropriate lock (or make the
> init-keyword be locked?: and use that to set the stream-lock).
>
> Obviously, some streams should be locked by default, like the standard-io
> streams for stdin, stdout, stderr.
>
> Short of that, we could do something like defaulting all string-streams to
> be unlocked, but that seems more confusing to document to me.
>
> What do other people think?
>
>  - 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