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

I think the key steps to moving forward with this are:


   - Try to identify why this change to stream locking was made in the
   first place and what changes will have to be made to applications as a
   result of this change. (Given that it was Hannes and Andreas, I'm assuming
   it was either DUIM/Gtk+ or Network Night Vision.)
   - Make the changes for the 2014.1 release and make sure that we explain
   them clearly.

I think that having locking in format-out and force-out will be sufficient
for many people.

 - Bruce



On Wed, Dec 18, 2013 at 9:23 AM, Ingo Albrecht <[email protected]> wrote:

> 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