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

[B. Fallenstein]

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?

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.


> > > > 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).


> > > > b) Listeners should not be abstract classes, since some people like to
> > > > implement them as mix-ins.
> > >
> > > Java has local classes so this is not necessarily a good thing.
> > > Mix-ins are usually used to get some *code*, which is impossible in Java.
> >
> > Hey, that's not a reason to be inconsistent! In Java, there is the strong
> > convention that Listeners are interfaces, and breaking conventions is always
> > bad (except if there's a really big gain, but that's not the case here).
>
> Ok, an interface and "Abstract*" implementation with empty methods (Adapter)?

Yes, that's precisely what I meant. Sorry for miscommunicating :-/


> > > > 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...

-b.