On 12/05/2013 07:54 AM, Shi Jun Zhang wrote:
On 11/30/2013 12:05 AM, Daniel Fuchs wrote:
On 11/29/13 4:56 PM, Alan Bateman wrote:
On 29/11/2013 10:08, Daniel Fuchs wrote:
However, removing or just moving the lock around might well
introduce new
unknown issues - so it will need to be carefully anaIyzed, and I am
not sure
it can/should be attempted in a minor JDK release.
Yes, we have to be very careful as the logging code has a history of
biting the hand of those that try to improve it. For various
reasons, it
seems there is a lot of code that has subtle dependencies on the
implementation, on the initialization in particular. In any case, you
are to be applauded for tackling the synchronization issues and it
would
be a good project to re-examine all of this in JDK 9 to see how it
would
be simplified.
On documenting the locking details in an @implNote (which seems to be
one of the suggestions here) then we also need to be careful as I think
we need some flexibility to change some of this going forward.
Yes - that's a two edged sword indeed. We certainly don't want to set
that in stone... On the other hand I empathizes with developers who
struggle to find out what they can - and can't do - when extending
j.u.l APIs...
Anyway, if usage of the 'synchronized' keyword never appears in
the Javadoc I guess that's for good reasons...
Thanks Alan,
-- daniel
-Alan
Hi Daniel,
This thread is silent for several days, do you have any finding in
Handler.publish?
Hi Shi Jun Zhang,
I have looked at this, creating a prototype. It re-arranged
synchronization in a way so that all Formatter methods are invoked out
of synchronized sections. I haven't come forward with this yet, because
of two issues:
- Formatter implementations would suddenly be called multi-threaded.
Currently they are invoked from within Handler-instance synchronized
sections.
- Formatter would have to be invoked optimistically to obtain head and
tail strings, so it could happen that a head, for example, would be
requested concurrently multiple times, but only one of returned heads
would be written to stream then.
The 1st thing seems problematic. I can imagine there exist Formatters
that are not thread-safe (for example, using single instance of
MessageFormat, which is not multi-threaded) and now just happen to work
as a consequence of current StreamHandler implementation detail, but
would break if called multi-threaded.
One way to remedy this is to add a boolean property to Formatter API,
say Formatter.isMultiThreaded(), and arrange so that appropriate
instances return appropriate values also considering
backwards-compatibility...
So all-in-all this is not a simple patch and I doubt it can be made for
JDK8. In JDK9, I think, it will be possible to re-visit this issue, so
It would be good to file it as a BUG or RFI.
Regards, Peter
