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

On Sat, Aug 3, 2013 at 9:03 PM, Hannes Mehnert <[email protected]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA384
>
> On 08/01/2013 05:39, Bruce Mitchener 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?
>
>
> I remember to have defaulted to make(<recursive-lock>) instead of #f
> with Andreas several years ago. Reasoning was that we were fixing
> multi-threaded applications (I believe mainly during gtk-duim work)
> and it was painful to debug.
> Our rationale was "better safe than sorry", which I still think should
> be the case.
> I think <string-stream> should not be locked by default.
>

I'm in agreement that we should have stdin / stdout be locked.  But having
this sort of locking on every file stream and so on seems like overkill to
me.  It isn't going to guarantee that things are right at all since if the
caller isn't handling locking correctly, then writes can still be readily
interleaved incorrectly.

There's a similar argument for stdin / stdout, but those seem less critical.

Were your issues back then just with stdin / stdout / stderr, or with
various file or socket streams?

I also envision a compiler optimization which looks whether the stream
> escapes or is local and if so, the compiler can remove the locking...
>

This seems a bit esoteric to me, especially compared to all of the other
compiler work to do. :)  (Although work to enable hardware lock elision
would be nice for those platforms that support that.)

 - Bruce

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