Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #18574

Re: Wormholes

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-03 18:12 -0700
  Re: Wormholes eric@invalid.com (EricF) - 2012-09-04 02:06 +0000
    Re: Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-04 10:08 -0700
    Re: Wormholes Wanja Gayk <brixomatic@yahoo.com> - 2012-09-09 13:55 +0200
  Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-03 22:34 -0400
    Re: Wormholes Stuart <DerTopper@web.de> - 2012-09-04 12:15 +0200
  Re: Wormholes markspace <-@.> - 2012-09-03 21:00 -0700
    Re: Wormholes Robert Klemme <shortcutter@googlemail.com> - 2012-09-04 07:08 +0200
  Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 08:47 +0200
    Re: Wormholes Lew <noone@lewscanon.com> - 2012-09-04 03:10 -0700
      Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 16:09 +0200
        Re: Wormholes Gene Wirchenko <genew@ocis.net> - 2012-09-04 08:34 -0700
          Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 17:46 +0200
            Re: Wormholes Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-04 09:31 -0700
        Re: Wormholes Lew <lewbloch@gmail.com> - 2012-09-04 11:14 -0700
        Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-04 19:59 -0400
    Re: Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-04 13:20 -0700
      Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-04 20:00 -0400
      Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:01 +0200
      Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:02 +0200
      Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:02 +0200
        Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:03 +0200
      Re: Wormholes markspace <-@.> - 2012-09-05 17:34 -0700
  Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-04 14:18 +0100
    Re: Wormholes Robert Klemme <shortcutter@googlemail.com> - 2012-09-05 21:51 +0200
      Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-05 23:26 +0100
        Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 09:32 +0000
          Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-06 11:47 +0100
            Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 15:10 +0000
              Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-06 20:12 +0100
                Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 21:08 +0000
  Re: Wormholes Nigel Wade <nmw@ion.le.ac.uk> - 2012-09-04 17:26 +0100
  Re: Wormholes Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-04 09:28 -0700
  Re: Wormholes David Lamb <dalamb@cs.queensu.ca> - 2012-09-04 16:54 -0400

csiph-web