Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm

[Tuomas Lukka]

On Thu, Nov 28, 2002 at 12:34:32PM +0200, B. Fallenstein wrote:
> 
> 
> Tuomas Lukka schrieb:
> 
> > On Wed, Nov 27, 2002 at 06:25:11PM +0100, address@hidden wrote:
> > > > > Hmm. Ok. First I was a bit worried about cases where we want blocking
> > > > > access (e.g. during startup, when we're waiting for the first pointer 
> > > > > to
> > > >
> > > > > be resolved and really cannot do anything else)-- but in these cases, 
> > > > > we
> > > >
> > > > > can write:
> > > > >
> > > > > listener = BlockingJobListener()
> > > > > while(true) {
> > > > > block = pool.get(id, listener);
> > > > > if(block != null) break;
> > > > > block.wait();
> > > > > }
> > > >
> > > > Ouch... that's not good. getSYNC()?
> > >
> > > ?
> >
> > Separate blocking method?
> 
> I don't like that-- blocking is too unusual to warrant a second method IMHO. 
> Can
> you explain why the above is not good?

Too complicated when just loading the space. We want to load at the first from
local store only.

> Hmm. What I would like is an easy way to get blocking access, but not through 
> a
> separate method; something like passing a special kind of listener, but don't
> know how.

Urgh! Awful.

> > > > > a) finished() is not specific to blocks: For most lookups, we want to 
> > > > > be
> > > >
> > > > > able to know when they're finished (e.g. pool.getIds()).
> > > >
> > > > Shouldn't pool.getIds() block?
> > >
> > > Why? It's a best-effort method anyway.
> >
> > Wait, now I don't understand. If it's best-effort, how can it be "finished"
> > at some point?
> 
> It is defined to be best-effort in the general case. For e.g. a 
> TransientPool, it
> is of course complete. In a network implementation, depending on the network
> architecture, there are two ways it can get finished: By a timeout, or 
> because we
> know that all data has been acquired (e.g. if this is a connection to a 
> server,
> and the server has returned all ids it has).

I'd really like to be able to know from this side of the API what is local
and what is not.

> > > > > c) I think timeout() and finished() will usually be implemented the 
> > > > > same
> > > >
> > > > > way, so why have two different methods?
> > > >
> > > > Really? For timeout() I'd usually do nothing, for finished, a redraw.
> > >
> > > When loading blocks maybe, but e.g. for pointers, if I don't know whether 
> > > I
> > > have complete data I still need to go on somehow...
> >
> > Hmm. I think we *really* need to make a document on what the intentions of
> > the async stuff is: which semantics are needed for getIds, which for getting
> > pointers, which for getting blocks, which for getting xu links, before
> > making the API. See above about the getIds.
> 
> I definitely need help there, since the problem is not clear to me. Since I
> cannot make myself clear apparently, I do see that we need such a document, 
> but I
> wouldn't know what to write in it...

I guess this would be the functional requirements for storm.

        Tuomas