Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Steven Simpson <ss@domain.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Wormholes
Date: Thu, 06 Sep 2012 20:12:54 +0100
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <m69nh9-663.ln1@s.simpson148.btinternet.com>
References: <0ska4895k2mp2j5fb5p4qnue7lsbdpoeoo@4ax.com> <9mbhh9-mce.ln1@s.simpson148.btinternet.com> <aapoq4F75iU1@mid.individual.net> <u40lh9-726.ln1@s.simpson148.btinternet.com> <slrnk4grd8.u9l.avl@gamma.logic.tuwien.ac.at> <libmh9-9h7.ln1@s.simpson148.btinternet.com> <slrnk4hf7o.u9l.avl@gamma.logic.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: mx04.eternal-september.org; posting-host="82310ab08bf578f62a5b66a5c4f3702f"; logging-data="976"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1++qkTYkEWf2h2YKUUNJCXUDdap4Y3pHDw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
In-Reply-To: <slrnk4hf7o.u9l.avl@gamma.logic.tuwien.ac.at>
Cancel-Lock: sha1:AwFV8hsjIEVcjKnWMyKi5xweaQI=
Xref: csiph.com comp.lang.java.programmer:18574

On 06/09/12 16:10, Andreas Leitgeb wrote:
> Back to the Box-example: as the Box-framework may not expect the
> getContent() call to depend on any outer local context, it might
> evaluate it earlier, and just return a cached result on your call.

No, not in this case.  The whole point of this framework is to create an 
internal structured representation of a file whose format is defined in 
terms of nested boxes - i.e. there's a parsing/deserialization phase too 
- and to allow those boxes to be manipulated.  After that, the point of 
the getContent() method is to serialize the hierarchy in its present 
state; getContent() has no advantage to cache anything, because the 
hierarchy is not ready to be serialized until getContent() is called.  
Its implementation is quite transparent - getFieldContent() will be 
called on each box as if by a depth-first traversal.  It is therefore 
relatively easy to offer informal guarantees about how a user's 
getFieldContent() will be invoked by getContent(), and the finality of 
Box's methods helps to prevent that from being undermined by subclasses.

Also, the extra context I'm providing does not affect the functional 
behaviour of the box structure.  It's there to regulate the arrival of 
bytes, so I can have the next batch already requested before the current 
batch has finished.

(Actually, it seems I haven't got that regulation quite right, so I've 
disabled it for now.  But I can add and remove it without changes to the 
box framework.)


> If the Box-framework really gave such a promise,
> then it had better provide a context parameter already, lest it be
> screwed itself.

The possibility of being screwed only comes if the getContent or 
getChildContent methods decide to call getFieldContent() indirectly by 
starting another thread.  For this framework, I don't foresee it 
happening.  Even if it did, I might be able still to make a lesser 
guarantee, that such threads are descendants of the original thread, so 
an InheritableThreadLocal would still work.

If even that's no good, and an extra parameter is required, what should 
it be, since the framework has no knowledge of how many or what types of 
contexts are required?  I already suggested a (different) Context and 
ContextLocal<T> pair of classes, but that is almost a dual of the 
ThreadLocal technique, but with the extra parameter made explicit, 
instead of implicitly being Thread.currentThread().  In other 
circumstances with fewer or weaker guarantees, I would do that, but I 
don't foresee ThreadLocal being a problem for this box framework.


-- 
ss at comp dot lancs dot ac dot uk