[interfacekit] Re: BLooper - PLEASE look at...

"Axel D=F6rfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> 
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > "Axel D=3DF6rfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> > > I am not sure it would be good to have that BLooper functionality 
> > > in 
> > > R1 
> > > - it would be nice if not needed that you could select a) the 
> > > port 
> > > it 
> > > should poll on, and b) how long it should wait for an incoming 
> > > message.
> > > Both things would be crucial for a good performance, but would 
> > > require 
> > > additional API which had a very short life-span.
> > Mmh, I don't see why this should be necessary. For R1 the new 
> > methods 
> > would be private anyway, and used only by BWindow (and one or two 
> > other 
> > classes). For the time being BLooper::task=3D5Flooper() would be 
> > implemented so, that BWindow behaves properly (the other concerned 
> > classes, too, of course), and for R2 only a minor change has to 
> > made 
> > to 
> > BLooper::task=3D5Flooper(), so that it works optimally in all cases.
> > 
> > I would favor this approach over implementing (i.e. cloning and 
> > extending) task=3D5Flooper() in all BLooper derived classes and 
> > needing 
> > to 
> > completely change them for R2.
> 
> I think I agree with you - but then, I would really use your API 
> change 
> to have a priority attached to every incoming port. The port with the 
> highest priority should be the port that the looper sits on.
> Now, the only thing missing would be a way to set the timeout of that 
> port. Of course, it might be enough to provide a standard value for 
> it. 

That should be OK for the time being, I think. I mean, even if we 
introduced a method to set that timeout, the caller would need to use 
some value, and that would probably be hardcoded anyway. :-)

> B=5FINFINITE=5FTIMEOUT if there is only one port to wait for, some other 
> value if there are more.

Yep.

CU, Ingo

Other related posts: