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

I favor opt-in locking.

Thread safety has to be ensured holistically. For the same reasons that atomic getters and setters do not guarantee thread safety and thread-safe collections do not guarantee safety, locked-by-default streams won’t guarantee safety. A properly-designed application will only read or write to a given resource on one thread, so locking gains you nothing.

Plus, that is what the authors of the IO library recommended: http://opendylan.org/documentation/library-reference/io/streams.html#locking-streams.


On Jul 31, 2013, at 8: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