Prev: Getting there....
Next: NYC LOCAL: Tuesday 10 August 2010 Lisp NYC Eating and Drinking
From: Captain Obvious on 12 Aug 2010 07:36
JCB> Well, in CLOS, class redefinition is an advertised feature supported
JCB> by an officially standard protocol (update-instance-for-???-class,
JCB> make-instances-obsolete). Considering that, the scenario I mentioned
JCB> is not far-fetched and is not an abuse of the system. So I think that
JCB> the issue here cannot be dismissed trivially.

I think the point is that application should not use classes _while_
redefining them.
Redefining classes is OK, but multi-threaded application should take
measures to maintain consistency and only do modifications when objects are
not in work.

From: Tim Bradshaw on 12 Aug 2010 14:06
On 2010-08-12 09:37:38 +0100, Jean-Claude Beaudoin said:

> Well, in CLOS, class redefinition is an advertised feature supported by
> an officially standard protocol (update-instance-for-???-class,
> make-instances-obsolete). Considering that, the scenario I mentioned is
> not far-fetched and is not an abuse of the system. So I think that the
> issue here cannot be dismissed trivially

Yes, redefinition is supported. But function redefinition, loading
code, and so on are also supported, and I seriously doubt if many
implementations are thread-safe in the presence of people (say) loading
patches.

Personally, I think that there's a fair amount to learn from Java here:
they originally had almost everything defined to be "thread safe" and
it turned out to hurt performance a good deal and not actually to help,
because making operations defined by the language/library thread safe
does not actually help programs, which tend to do more than one of thse
things, be thread safe: the programs needed to interlock *anyway*. So
the second generation of Java stuff (Java 2?) had a lot less thead-safe
things.

If I was going to spend time thinking about CLOS and thread-safety, the
approach I'd take would be to think about sealing, and specifically the
ability to seal parts of the system while leaving others unsealed. If
you, say, seal a generic function, then you *know* people will not be
defining new methods on it, and for added value you can do a lot of
work to optimise it, because the sealing declaration licenses that as
well. Similarly sealing classes allows a lot of nice assumptions to be
made. Finally sealing declarations are great ways of expressing intent
(in the same way that type declarations can be in CL, even when there
is no expectation that the system will enforce them). It's a long time
since I read the Dylan documentation (probably not since it had an
sexp-based syntax in fact), but I remember they seemed to have quite a
good approach to this - probably not surprising since the Dylan object
system is very much a post-CLOS system, if I remember rightly.

From: Tim Bradshaw on 12 Aug 2010 14:07
On 2010-08-12 12:36:17 +0100, Captain Obvious said:

> I think the point is that application should not use classes _while_
> redefining them.
> Redefining classes is OK, but multi-threaded application should take
> measures to maintain consistency and only do modifications when objects
> are not in work.

Exactly. In just the same way that one would not expect to use a
system while it was being recompiled & loaded (or if that was
supported, which it can be, you wuld expect to do a lot of
application-level work to make it work properly)

First  |  Prev  | 
Pages: 1 2 3
Prev: Getting there....
Next: NYC LOCAL: Tuesday 10 August 2010 Lisp NYC Eating and Drinking