Re: Synchronization questions

2004-01-31 Thread Peter B. West
Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
I've been hacking the tree methods in Node recently
...
Are you talking 'maintenance vs. HEAD' here?

No.  I realise the message was ambiguous.  I was talking about versions 
of my general tree-handling classes - Node (primarily) and Tree.

My first change was to synchronize the methods which had previously been
synchronized on the Tree, but I realized that such synchronization of
methods in inner classes probably only synchronized on the actual inner
class instance, not on the containing class instance.  Does anyone have
any knowledge of this?


Hmm... Difficult to tell from the docs I read, so far... I'd say: indeed,
unless the code-block through which the inner class (synchronized) method is
accessed is synchronized on the containing class instance, no? Then again,
synchronizing only on the inner classes could turn out to offer more
flexibility, as other operations on the containing class can still be
carried out while the inner class is locked (provided, of course, that the
'other' operations do not need access to the inner class instance...)
In this case they do need such access.  The inner classes are iterators.


It also occurred to me that optional synchronization might be a good
idea, allowing a common synchronization object to be passed to the Node
constructor.  An alternative was to allow optional synchronization, but
to synchronize on the affected Node object.  On the construction of any
particular Node, a boolean can be passed indicating the need for
synchronization.


The other solution for the above stated issue: remove the synchronization
from the inner class methods, and synchronize their bodies on the containing
class instance. (Again: IIC you'd only need this if you really *need* to
synchronize on the outer class... if you don't, I guess the approach you're
taking now is more flexible and less likely to lead to deadlocks.)
I was worried about increasing the probability of deadlock by having 
many more locks held concurrently.  Without having thought about it a 
great deal, it seems to me that it is easier to appreciate and avoid 
potential deadlocks when synchronization is more global, as with the 
synchronization on the containing Tree object.

snip /

Does anyone have experience with such issues?



No real experience, but thinking about 'optional synchronization' brings up
all sorts of ideas, like:
- a Lockable interface for Nodes
- a SyncedNode extending Node implementing the Lockable interface
- when you really only need a non- or partly synchronized Node use the main
type; if you need a fully synchronized one, use the subtype
(ratio of execution speeds from non-synced vs. synced is roughly 100 vs.
150, so it would definitely be worth it to avoid synchronization altogether
where it is not strictly necessary)
This would be the clean way to express the current version of the code. 
 However, I am still toying with the idea of allowing (sub)trees to 
synchronize on an object passed in as a parameter to the Node 
constructor.  If the object reference is null, synchronization is turned 
off.  In this scheme, I would allow subclasses (like Area) to switch 
synchronization on by setting the 'sync' object non-null, as, for 
example, when a locally constructed subtree was grafted onto the 
AreaTree.  It also returns to the situation of a common synchronization 
object for each node in the (sub)tree.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: Synchronization questions

2004-01-31 Thread Peter B. West
Peter B. West wrote:
This would be the clean way to express the current version of the code. 
 However, I am still toying with the idea of allowing (sub)trees to 
synchronize on an object passed in as a parameter to the Node 
constructor.  If the object reference is null, synchronization is turned 
off.  In this scheme, I would allow subclasses (like Area) to switch 
synchronization on by setting the 'sync' object non-null, as, for 
example, when a locally constructed subtree was grafted onto the 
AreaTree.  It also returns to the situation of a common synchronization 
object for each node in the (sub)tree.
The notion of switching synchronization on and off is, unfortunately, 
brain-dead.  If synchronization is to be changed, then the code which 
changes and reads the synchronization state must itself be synchronized.

The conditional synchronization that I have now is only workable because 
the setting for any particular node is immutable.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


RE: Synchronization questions

2004-01-31 Thread Andreas L. Delmelle
 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]
snip /
 
 
 It also occurred to me that optional synchronization might be a good
 idea, allowing a common synchronization object to be passed to the Node
 constructor.  An alternative was to allow optional synchronization, but
 to synchronize on the affected Node object.  On the construction of any
 particular Node, a boolean can be passed indicating the need for
 synchronization.
 
 [Me :]
  The other solution for the above stated issue: remove the
 synchronization
  from the inner class methods, and synchronize their bodies on
 the containing
  class instance. (Again: IIC you'd only need this if you really *need* to
  synchronize on the outer class... if you don't, I guess the
 approach you're
  taking now is more flexible and less likely to lead to deadlocks.)
 

 I was worried about increasing the probability of deadlock by having
 many more locks held concurrently.  Without having thought about it a
 great deal, it seems to me that it is easier to appreciate and avoid
 potential deadlocks when synchronization is more global, as with the
 synchronization on the containing Tree object.


Yes, I see what you mean... Well, as I indicated, there's absolutely no
reason to trust me on this. Your view is probably more to the point here.
The only thing I do know for sure is that many authors claim that most
possible cases of deadlock can --and should preferrably be - identified in
advance (i.e. before any code is ever written).
The two most common cases of deadlock are AFAIK:
1. A thread that doesn't exit (cleanly), so never releases the lock (threads
going into an infinite loop belong to this category)
2. Two threads 'waiting for each other': one holding the lock and waiting
for a return value from the second, the other needing access to the locked
object in order to return the desired value.

So it would come down to predicting in some way the risk of either of these
two taking place.
I guess that, when synchronization is more global, the first type would be
easier to avoid. Mostly, it's also advised not to synchronize *every*
method, actually leaving a backdoor opened to be able to cleanly open the
lock from the inside (--but I'm guessing this is well-known fact to you).
This would be an argument against all-too-eagerly-global synchronization
IMHO.
(On top of that, but this may be a consequence of the limitation of my
understanding of the FO process in its entirety, it seemed easier to me to
avoid the first cases manually and the second by design, than doing it the
other way around. I'm still not completely familiar with the 'borderline'
cases, where an event downstream would influence upstream events in such a
way that they might need access to a Node on which a lock is being held by
another process...)

  snip /
   However, I am still toying with the idea of allowing (sub)trees to
 synchronize on an object passed in as a parameter to the Node
 constructor.  If the object reference is null, synchronization is turned
 off.  In this scheme, I would allow subclasses (like Area) to switch
 synchronization on by setting the 'sync' object non-null, as, for
 example, when a locally constructed subtree was grafted onto the
 AreaTree.  It also returns to the situation of a common synchronization
 object for each node in the (sub)tree.

 [Your follow-up: ]
 The notion of switching synchronization on and off is, unfortunately,
 brain-dead.  If synchronization is to be changed, then the code which
 changes and reads the synchronization state must itself be synchronized.

 The conditional synchronization that I have now is only workable because
 the setting for any particular node is immutable.

And so if you need a non-synched version of the same Node, you would need to
create a non-synched clone/copy (--preferrably disposable)?

Cheers,

Andreas



Nasty layout bug: maint vs. HEAD

2004-01-31 Thread Andreas L. Delmelle


Tried the following type of FO-document:

- one page-sequence with a sort of TOC, a fo:table with basic-links to
detail-blocks
- multiple page-sequences, one for each detail-block

In the test document, the TOC is about five pages, containing links to +/-
300 detail-blocks. The detail-blocks all take up one page each (for the
moment).

In 0.20.5 this works very fine... In HEAD strangely the document is layed
out such that the first TOC page ends up after the last detail-block for
which it contains the link...

Does anybody have an idea where the origin of this weirdness might be
located? :)

Cheers,

Andreas



Re: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread J.Pietschmann
Andreas L. Delmelle wrote:
In 0.20.5 this works very fine... In HEAD strangely the document is layed
  ^
  laid :-)
out such that the first TOC page ends up after the last detail-block for
which it contains the link...
I don't understand the problem. Could you trim it down to two detail blocks,
and post the FO (assuming the trimmed down FO still has the problem)?
J.Pietschmann


Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

2004-01-31 Thread Simon Pepping
On Mon, Jan 26, 2004 at 11:32:22AM -, [EMAIL PROTECTED] wrote:
 
 This patch is intended as inspiration and as an example of the discussion found 
 here:
 
http://marc.theaimsgroup.com/?l=fop-devm=107511296910230w=2
 
 The patch includes the following:
 
 - unnests the Property.Maker classes.
 - moves the PropertyMakers into properties
 - Rolls the datatypes into the property classes.
 - Moves the property classes into datatypes.

I have the following considerations:

1. The old situation has pure datatypes, which in theory may be reused
   in other situations. In practice, these datatypes are very much
   bound to properties, so that reuse is not realistic, and does not
   happen in FOP code. Combining the notions of datatype and property
   is more tuned to FOP's situation.

2. Even in the old situation the separation between datatypes and
   properties is not complete. Compound datatypes contain properties.

3. In code where the datatype aspect is used, the code may become less
   logical. This happens in the parsers and in the RTF renderer. An
   example from render/rtf/TextAttributesConverter.java:

// Cell background color
ColorTypeProperty colorTypeProp = 
(ColorTypeProperty)propertyList.get(Constants.PR_COLOR);
if (colorTypeProp != null) {
ColorTypeProperty colorType = colorTypeProp.getColorType();
if (colorType != null) {
if (colorType.getAlpha() != 0
|| colorType.getRed() != 0
|| colorType.getGreen() != 0
|| colorType.getBlue() != 0) {
rtfAttr.set(
RtfText.ATTR_FONT_COLOR,
convertFOPColorToRTF(colorType));
}

   Here colorTypeProp and colorType denote the same, and the code is
   not quite logical. That is because the method getColorType now more
   acts as an assertion. In the new situation it could be made more
   logical as follows:

// Cell background color
ColorTypeProperty colorType = 
(ColorTypeProperty)propertyList.get(Constants.PR_COLOR);
if (colorType != null  colorType.getColorType() != null) {
if (colorType.getAlpha() != 0
|| colorType.getRed() != 0
|| colorType.getGreen() != 0
|| colorType.getBlue() != 0) {
rtfAttr.set(
RtfText.ATTR_FONT_COLOR,
convertFOPColorToRTF(colorType));
}

   Therefore, in the new situation people might want to do some
   rewriting.

All in all I think that this change simplifies the code, and would be
a good change.

Allow me to make some notes:

1. Would it not be a good idea to move Property.java from fo to
   properties?

2. TableColLength and LinearCombinationLength do not have the word
   'Property' in their name. I would advocate making these names
   consistent with the others.

3. Should ToBeImplemented.java also be removed?

A lot of good work.

Regards,
Simon Pepping

-- 
Simon Pepping
home page: http://www.leverkruid.nl



RE: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

2004-01-31 Thread Andreas L. Delmelle
 -Original Message-
 From: Simon Pepping [mailto:[EMAIL PROTECTED]

snip /
 All in all I think that this change simplifies the code, and would be
 a good change.

 Allow me to make some notes:

 1. Would it not be a good idea to move Property.java from fo to
properties?


A question that was on the tip of my tongue too... I'd think: not only
Property.java, but all related Maker-classes as well.

snip /
 3. Should ToBeImplemented.java also be removed?

In the long run, that *should* be the objective indeed. For the moment, I'd
leave that right where it is, until we're sure we've no more refs to it
hidden somewhere else in the code.


Cheers,

Andreas



RE: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread Andreas L. Delmelle
 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]

 Andreas L. Delmelle wrote:
  In 0.20.5 this works very fine... In HEAD strangely the
 document is layed

  ^

  laid :-)


Ahem... Sorry 'bout that.

  out such that the first TOC page ends up after the last detail-block for
  which it contains the link...

 I don't understand the problem. Could you trim it down to two
 detail blocks,
 and post the FO (assuming the trimmed down FO still has the problem)?


Sure. In attach.

Cheers,

Andreas


testrekov.fo
Description: Binary data


Re: Updating licenses

2004-01-31 Thread Jeremias Maerki
Very cool! I did the whole thing manually back when I exchanged the
illegal short licence with the long one.

But I noticed the following:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java?rev=1.2.2.1

It looks like the {YEARS} marker seems not to have worked on some files
you checked in yesterday.

On 30.01.2004 00:00:46 Peter B. West wrote:
 Fops,
 
 I have committed the perl script bin/lic_to_2 in FOP_0-20-0_Alt-Design. 
   It's function is to substitute license 2.0 for 1.1.
 
 It is called as
 
 $ lic_to_2 --lic2 {file containing license 2.0 text} {file to modify}
 
 The intended usage is something like:
 
 $ find . -name '*java'|while read file;\
 mv $file $file.orig;\
 do lic_to_2 --lic2 {lic2 file} $file.orig  $file;\
 done
 
 I have already committed java and plain text versions of 2.0 to the root 
 directory of FOP_0-20-0_Alt-Design.  Note that these license files 
 contain a {YEARS} marker which is replaced from the actual years in the 
 source file copyright notice when the script is run.
 
 When we get the OK, I'll use this to update the licenses in alt-design, 
 and, if that works, I can also do the maint and HEAD sources.


Jeremias Maerki



DO NOT REPLY [Bug 17999] - @border in fo:block : overwrites area page margin

2004-01-31 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999

@border in fo:block : overwrites area  page margin





--- Additional Comments From [EMAIL PROTECTED]  2004-01-31 22:46 ---
Created an attachment (id=10171)
PDF illustraion


DO NOT REPLY [Bug 17999] - @border in fo:block : overwrites area page margin

2004-01-31 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999

@border in fo:block : overwrites area  page margin





--- Additional Comments From [EMAIL PROTECTED]  2004-01-31 22:49 ---
I've attached a illustrating PDF example
There is a fix though. use padding and set margin to 0.

Works for me, see illustration. So maybe there is a bug in the padding
calculation routine if margin is not set.

Though margin seems buggy too.

I've tried to document as good as possible in the pdf.

I ran across this when doing an envelope window + folding marker page as you can
see.

kindest regards,
 moritz angermann


RE: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread Andreas L. Delmelle
 -Original Message-
 From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
  -Original Message-
  From: J.Pietschmann [mailto:[EMAIL PROTECTED]
 
 
  I don't understand the problem. Could you trim it down to two
  detail blocks,
  and post the FO (assuming the trimmed down FO still has the problem)?
 

 Sure. In attach.


To clear that up a bit further:

If you run a document structured like this, but with many more
page-sequences, through HEAD, the whole document will be divided into chunks
of about 60 pages ( +/- the number of lines in the table-body of the TOC ),
and in between you will find the TOC pages themselves.

I must admit: it *does* have a certain logic to it I can appreciate, but it
would somehow seem far from compliant :)

Cheers,

Andreas



Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

2004-01-31 Thread Peter B. West
Simon Pepping wrote:
I have the following considerations:

1. The old situation has pure datatypes, which in theory may be reused
   in other situations. In practice, these datatypes are very much
   bound to properties, so that reuse is not realistic, and does not
   happen in FOP code. Combining the notions of datatype and property
   is more tuned to FOP's situation.
Alt-design has completely separate properties and data-types.  Instances 
of datatypes contain int references to the property on which they were 
defined.
2. Even in the old situation the separation between datatypes and
   properties is not complete. Compound datatypes contain properties.
Alt-design has no compound properties.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: Updating licenses

2004-01-31 Thread Peter B. West
Jeremias Maerki wrote:
Very cool! I did the whole thing manually back when I exchanged the
illegal short licence with the long one.
But I noticed the following:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java?rev=1.2.2.1
It looks like the {YEARS} marker seems not to have worked on some files
you checked in yesterday.
Ahem...

That's because I cut-and-pasted the 2.0 license file into the pattern 
Eclipse uses when constructing a new class.  I forgot to fix {YEARS}. 
Those new files haven't been run through the perl filter.  Thanks for 
picking this up, Jeremias.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


cvs commit: xml-fop/src/java/org/apache/fop/area BlockContainer.java BlockArea.java ReferenceArea.java

2004-01-31 Thread pbwest
pbwest  2004/01/31 21:47:38

  Modified:src/java/org/apache/fop/area/inline Tag:
FOP_0-20-0_Alt-Design InlineArea.java
InlineContainer.java
   src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
BlockContainer.java BlockArea.java
ReferenceArea.java
  Log:
  Fixed Copyright year.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.2.2.2   +1 -1  xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java
  
  Index: InlineArea.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java,v
  retrieving revision 1.2.2.1
  retrieving revision 1.2.2.2
  diff -u -r1.2.2.1 -r1.2.2.2
  --- InlineArea.java   30 Jan 2004 05:52:43 -  1.2.2.1
  +++ InlineArea.java   1 Feb 2004 05:47:38 -   1.2.2.2
  @@ -1,6 +1,6 @@
   /*
*
  - * Copyright {YEARS} The Apache Software Foundation.
  + * Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
  
  
  
  1.1.2.2   +3 -3  
xml-fop/src/java/org/apache/fop/area/inline/Attic/InlineContainer.java
  
  Index: InlineContainer.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/area/inline/Attic/InlineContainer.java,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- InlineContainer.java  30 Jan 2004 05:52:43 -  1.1.2.1
  +++ InlineContainer.java  1 Feb 2004 05:47:38 -   1.1.2.2
  @@ -1,6 +1,6 @@
   /*
*
  - * Copyright {YEARS} The Apache Software Foundation.
  + * Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
  
  
  
  No   revision
  No   revision
  1.1.2.2   +3 -3  xml-fop/src/java/org/apache/fop/area/Attic/BlockContainer.java
  
  Index: BlockContainer.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/BlockContainer.java,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- BlockContainer.java   30 Jan 2004 05:51:07 -  1.1.2.1
  +++ BlockContainer.java   1 Feb 2004 05:47:38 -   1.1.2.2
  @@ -1,6 +1,6 @@
   /*
*
  - * Copyright {YEARS} The Apache Software Foundation.
  + * Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
  
  
  
  1.1.2.2   +3 -3  xml-fop/src/java/org/apache/fop/area/Attic/BlockArea.java
  
  Index: BlockArea.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/BlockArea.java,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- BlockArea.java30 Jan 2004 05:51:07 -  1.1.2.1
  +++ BlockArea.java1 Feb 2004 05:47:38 -   1.1.2.2
  @@ -1,6 +1,6 @@
   /*
*
  - * Copyright {YEARS} The Apache Software Foundation.
  + * Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
  
  
  
  1.1.2.2   +3 -3  xml-fop/src/java/org/apache/fop/area/Attic/ReferenceArea.java
  
  Index: ReferenceArea.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/ReferenceArea.java,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- ReferenceArea.java30 Jan 2004 05:51:07 -  1.1.2.1
  +++ ReferenceArea.java1 Feb 2004 05:47:38 -   1.1.2.2
  @@ -1,6 +1,6 @@
   /*
*
  - * Copyright {YEARS} The Apache Software Foundation.
  + * Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: xml-fop/src/java/org/apache/fop/area TransformMatrix.java

2004-01-31 Thread pbwest
pbwest  2004/01/31 21:49:10

  Modified:src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
TransformMatrix.java
  Log:
  Fixed Copyright years.
  Varioable name changes to match type name.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.2   +32 -32xml-fop/src/java/org/apache/fop/area/Attic/TransformMatrix.java
  
  Index: TransformMatrix.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/TransformMatrix.java,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- TransformMatrix.java  30 Jan 2004 05:52:13 -  1.1.2.1
  +++ TransformMatrix.java  1 Feb 2004 05:49:10 -   1.1.2.2
  @@ -4,7 +4,7 @@
*The Apache Software License, Version 1.1
* 
*
  - * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
  + * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved
*
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
  @@ -57,7 +57,7 @@
   import org.apache.fop.fo.properties.WritingMode;
   
   /**
  - * Describe a PDF or PostScript style coordinate transformation matrix 
(TransformMatrix).
  + * Describe a PDF or PostScript style coordinate transformation matrix.
* The matrix encodes translations, scaling and rotations of the coordinate
* system used to render pages.
*/
  @@ -65,11 +65,11 @@
   
   private double a, b, c, d, e, f;
   
  -private static final TransformMatrix CTM_LRTB =
  +private static final TransformMatrix TM_LRTB =
   new TransformMatrix(1, 0, 0, 1, 0, 0);
  -private static final TransformMatrix CTM_RLTB =
  +private static final TransformMatrix TM_RLTB =
   new TransformMatrix(-1, 0, 0, 1, 0, 0);
  -private static final TransformMatrix CTM_TBRL =
  +private static final TransformMatrix TM_TBRL =
   new TransformMatrix(0, 1, -1, 0, 0, 0);
   
   /**
  @@ -123,15 +123,15 @@
   /**
* Initialize a TransformMatrix with the values of another TransformMatrix.
*
  - * @param ctm another TransformMatrix
  + * @param tm another TransformMatrix
*/
  -protected TransformMatrix(TransformMatrix ctm) {
  -this.a = ctm.a;
  -this.b = ctm.b;
  -this.c = ctm.c;
  -this.d = ctm.d;
  -this.e = ctm.e;
  -this.f = ctm.f;
  +protected TransformMatrix(TransformMatrix tm) {
  +this.a = tm.a;
  +this.b = tm.b;
  +this.c = tm.c;
  +this.d = tm.d;
  +this.e = tm.e;
  +this.f = tm.f;
   }
   
   /**
  @@ -145,23 +145,23 @@
* TransformMatrix is being set.
* @return a new TransformMatrix with the required transform
*/
  -public static TransformMatrix getWMctm(int wm, int ipd, int bpd) {
  -TransformMatrix wmctm;
  +public static TransformMatrix getWMtm(int wm, int ipd, int bpd) {
  +TransformMatrix wmtm;
   switch (wm) {
   case WritingMode.LR_TB:
  -return new TransformMatrix(CTM_LRTB);
  +return new TransformMatrix(TM_LRTB);
   case WritingMode.RL_TB: {
  -wmctm = new TransformMatrix(CTM_RLTB);
  -wmctm.e = ipd;
  -return wmctm;
  +wmtm = new TransformMatrix(TM_RLTB);
  +wmtm.e = ipd;
  +return wmtm;
   }
  -//return  CTM_RLTB.translate(ipd, 0);
  +//return  TM_RLTB.translate(ipd, 0);
   case WritingMode.TB_RL: { // CJK
  -wmctm = new TransformMatrix(CTM_TBRL);
  -wmctm.e = bpd;
  -return wmctm;
  +wmtm = new TransformMatrix(TM_TBRL);
  +wmtm.e = bpd;
  +return wmtm;
   }
  -//return CTM_TBRL.translate(0, ipd);
  +//return TM_TBRL.translate(0, ipd);
   default:
   return null;
   }
  @@ -323,7 +323,7 @@
* (Note: scrolling between region vp and ref area when
* doing online content!)
*/
  -TransformMatrix ctm = 
  +TransformMatrix tm = 
   new TransformMatrix(absVPrect.getX(), absVPrect.getY());
   
   // First transform for rotation
  @@ -332,16 +332,16 @@
   // first quadrant. Note: rotation is counter-clockwise
   switch (absRefOrient) {
   case 90:
  -ctm = ctm.translate(0, width); // 

Re: Synchronization questions

2004-01-31 Thread Peter B. West
Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
...

I was worried about increasing the probability of deadlock by having
many more locks held concurrently.  Without having thought about it a
great deal, it seems to me that it is easier to appreciate and avoid
potential deadlocks when synchronization is more global, as with the
synchronization on the containing Tree object.


Yes, I see what you mean... Well, as I indicated, there's absolutely no
reason to trust me on this. Your view is probably more to the point here.
The only thing I do know for sure is that many authors claim that most
possible cases of deadlock can --and should preferrably be - identified in
advance (i.e. before any code is ever written).
The two most common cases of deadlock are AFAIK:
1. A thread that doesn't exit (cleanly), so never releases the lock (threads
going into an infinite loop belong to this category)
This is always going to be tricky.

2. Two threads 'waiting for each other': one holding the lock and waiting
for a return value from the second, the other needing access to the locked
object in order to return the desired value.
See comments below.
So it would come down to predicting in some way the risk of either of these
two taking place.
I guess that, when synchronization is more global, the first type would be
easier to avoid. Mostly, it's also advised not to synchronize *every*
method, actually leaving a backdoor opened to be able to cleanly open the
lock from the inside (--but I'm guessing this is well-known fact to you).
This would be an argument against all-too-eagerly-global synchronization
IMHO.
It's only necessary to synchronize the methods that read or modify the 
data that is in contention.  I suspect that a lot of synchronized code 
is written by those who don't quite understand why, and who take the 
first approach that seems to work.  I get the feeling that quick and 
easy approaches are frequently encouraged.

(On top of that, but this may be a consequence of the limitation of my
understanding of the FO process in its entirety, it seemed easier to me to
avoid the first cases manually and the second by design, than doing it the
other way around. I'm still not completely familiar with the 'borderline'
cases, where an event downstream would influence upstream events in such a
way that they might need access to a Node on which a lock is being held by
another process...)
Deadlock problems have to be considered carefully at the design stage.

In my original considerations for the pipelined model of alt-design, I 
was happy to have blocking writes/reads on the buffers of the primary 
pipeline (parser-fo tree builder-area tree builder), but I thought 
there would be deadlock problems if the return message queues were 
blocking.  (See figure 3 - incorrectly captioned Figure 2 - of 
http://xml.apache.org/fop/design/alt.design/xml-parsing.html).  I 
believe that the less complicated the synchronization structure, the 
easier it will be to analyse the possibilities for deadlock, hence my 
interest in getting back to more global synchronization objects.

snip /
 However, I am still toying with the idea of allowing (sub)trees to
synchronize on an object passed in as a parameter to the Node
constructor.  If the object reference is null, synchronization is turned
off.  In this scheme, I would allow subclasses (like Area) to switch
synchronization on by setting the 'sync' object non-null, as, for
example, when a locally constructed subtree was grafted onto the
AreaTree.  It also returns to the situation of a common synchronization
object for each node in the (sub)tree.
[Your follow-up: ]
The notion of switching synchronization on and off is, unfortunately,
brain-dead.  If synchronization is to be changed, then the code which
changes and reads the synchronization state must itself be synchronized.
The conditional synchronization that I have now is only workable because
the setting for any particular node is immutable.


And so if you need a non-synched version of the same Node, you would need to
create a non-synched clone/copy (--preferrably disposable)?
It seems to be the only way to do it.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html