[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm
From: |
Tuomas Lukka |
Subject: |
Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm |
Date: |
Thu, 28 Nov 2002 12:28:04 +0200 |
User-agent: |
Mutt/1.4i |
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?
> > > 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?
Could you go through the semantics again?
> > > 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)?
> > > 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.
Tuomas
- [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm, Benja Fallenstein, 2002/11/24
- Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm, Tuomas Lukka, 2002/11/26
- Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm, Benja Fallenstein, 2002/11/26
- Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm, Tuomas Lukka, 2002/11/27
- Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm, b . fallenstein, 2002/11/27
- Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm,
Tuomas Lukka <=
- Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm, B. Fallenstein, 2002/11/28
- Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm, Tuomas Lukka, 2002/11/28
- Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm, B. Fallenstein, 2002/11/28