river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: VOTE: add Startable to Jini specification
Date Thu, 19 Dec 2013 20:27:03 GMT
On 12/19/2013 12:16 PM, Greg Trasuk wrote:
> +0.  Let me explain…
> Having a separate interface to say start() is all very well and harmless in itself, but:
> (a) It doesn’t really address the issue of how service instances
should be started. We don’t actually have solid recommendations on this
issue, although there have been attempts in various containers to
systematize it.
> (b) the proposed warning addresses a case where a service instance
> is
doing “exporter.export(this);”, which I’d call bad practice in any case.
It happens that ServiceStarter appears to encourage this use case
because it works by calling a constructor. But the called constructor
could (and should) construct an instance of some other class, and then
export and register that instance rather than “this”. That style doesn’t
mandate a Startable interface, and having Startable doesn’t mandate good
multi-threaded code. In other words, you could implement Startable and
still have poor thread-safety.

And, using, for example, the strategy you describe of constructing
another object, code can be perfectly valid without using Startable. I
see value in offering the interface, and a rule that the start method
will be called after the constructor for any service implementing it. I
don't think River should assume code is not safe just because it does
not use that feature - it may be safe for entirely different reasons.

> (c) even where there is an apparent problem, the exposure window is
very small.

Remember an exposure window can be small in terms of numbers of
statements, but long in terms of elapsed time. Leaving apparently small
windows open can result in code that fails mysteriously, for example
when a page boundary happens to fall in the window, and the system is
under memory pressure.


View raw message