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

"Adi Oanca" <e2joseph@xxxxxxxxxx> wrote:
[...]
> > Just snoozing would have many disadvantages, for example it could 
> > slow
> > down message handling.
> 
>     How is this possible=3F=3F=3F=3F=3F If look close, snooze() is called 
> ONLY 
> if
> there isn't any message to handle! snooze(5), is equivalent to Java's
> yield() - YOU said that! So, the purpose of snooze(5) is JUST to 
> reschedule
> the thread, because, as I said, we do not want to use our timeslice 
> in
> vain!!!
>     Now... Why is your method MUCH  BETTER=3F=3F=3F I would say that none 
> is
> better, they are equal!

snooze(5) is not equivalent to Java yield(), since at least according 
to the specification it is supposed to wait at least 5 us. I'm not sure 
about the timer granularity -- in practice it may indeed not wait at 
all (besides being rescheduled), or wait at least a longer interval.

Directly waiting on the port on the other hand will allow the thread to 
return immediatly, when a new message arrives. In case a new message 
arrived since the last port=5Fcount() (mind you, the thread could have 
been preempted inbetween) it may even not need to be rescheduled.

[...]
> > It's only very
> > rarely needed to do something like this in real life,
> 
>     I do not agree! I studied Computer Engineering for 2 years ( now 
> I'm in
> 4th year in Computer Science) and, I would really like the ability to 
> read
> form the serial port transform raw data into BMessages and dispatch 
> them
> with BLooper!

If you want to use BSerialPort, then you can employ an additional 
thread, use blocking reading, add the read data to a message, and post 
it to the looper in question. No polling needed.

>     Also... what you do not know... Erik recently told me... BWindow 
> in R5
> doesn't have 2 ports opened!!! Messaging between BWindow(not sure 
> about
> BApplication) and app=5Fserver is done through a shared memory area!!!

While I'm willing to believe, that BWindow also communicates via shared 
memory with the app server, listport tells me, that for each window 
ports like these (for a Terminal window in this case) exist:

75786       p>      Terminal 2:107        12       0
75787       p<      Terminal 2:107        12       0

> > so it's not urgently needed right now.
> 
>     No=3F Hey! We'll wait till you say it's time!
> 
>     THIS will happen! The quicker, the better!
>     In my country there is a saying: Don't let for tomorrow, things 
> you can
> do today!

Something like this exists in every country, I suppose. :-)

[...]
> > along with an extended form of BLooper::GetMessageFromPort() which
> > specifies the port number or something like this.
> 
>     Yes... in my implementation it's called: void*
> ReadRawFromOtherSources(). I proffered to make this method virtual 
> because I
> thought that the code needed to translate raw data into BMessages 
> should be
> done in one place: ConvertToMessage(...)

There is a significant difference between your 
ReadRawFromOtherSources() and Axel's GetMessageFromPort(). Your 
approach requires polling by design, while Axel's idea allows us to get 
rid of polling as soon as we something like a 
wait=5Ffor=5Fmultiple=5Fobjects().

> Ingo wrote:
[...]
> > The priority wouldn't be of relevance for waiting for messages, but 
> > for
> > fetching the messages from the port. I.e. if there are messages 
> > waiting
> > at two ports, the port with the higher priority would be served 
> > first.
> > If I understood it correctly, the messages arriving at a BWindow's 
> > app
> > server port should have priority over the looper messages.
> 
>     That could very easily be done! The first(or the last) port added 
> to the
> list would be read before its predecessor, and so on.

Or, as proposed, by priorities, which would imply the order of the 
ports.

[...]

> Axel wrote:
> > 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.
> 
>     I think it's better to use my method (snooze(5)).There isn't a 
> need to
> sit a bit longer on the port with the higher priority; It may render 
> out
> looper a bit unresponsiveness!

Why is that=3F In case no message arrives a read=5Fport=5Fetc() with timeout 
n has the same effect as a snooze(n). But if a message arrives, this is 
better, since we will be woken up even earlier.

[...]
> Guys! I know that the method I proposed isn't the best, but it can be 
> used
> in many circumstances!
>     What Axel suggested, AddPort(), is a cleaner approach, but, what 
> should
> we do, if one would want to read from an area or a serial port(yes, 
> USB,
> too)=3F I've told you, without those extensions, very few will use 
> BLooper as
> a parent class!

This isn't about making BLooper a class usable for every purpose. Yes, 
we could add a kitching sink, but that wouldn't fit very well into what 
the class is intend for. BLooper is an autonomous message receiver and 
dispatcher, not more, not less. I'm actually even sceptical about ever 
making the said AddPort() extension a public API. It seems to make 
sense for BWindow and BDirectWindow to use a `privileged' port for 
communication with the app server, but I can't really imagine other 
applications for which one would need a separate port.

For the serial port (one may ask whether this makes sense at all, 
anyway), as said above, one can employ a separate thread, which simply 
posts the messages to the looper. For the reading from an area, I 
think, one would certainly synchronize the communication via a 
semaphore anyway, and then the same as for the serial port applies.

>     BTW, Axel, how can wait=5Ffor=5Fmultiple=5Fobjects() work for a serial 
> port=3F
> 
>     Ohh, ... I almost forgot! What should we do if someone overrides
> task=5Flooper()=3F How can we make it quit=3F

task=5Flooper() is private and should remain so. So, let alone our 
classes there won't be anyone else.

>     We should resolve this issue in R2 by making talk=5Flooper() non-
> virtual
> and adding a new class BThread. What do you think=3F

As long as we want to retain binary compatibility, we don't have the 
choice to make task=5Flooper() non-virtual.

Regarding BThread, I'm not sure, what we would gain. I found the idea 
compelling myself years ago, but my experience shows that there are 
little benefits in the best, but problems in the worst case. In the 
Tracker sources one can find such a class (actually a class hierarchy), 
but it is used there basically as a nice cover for invoking 
spawn=5Fthread() on functions/methods typed differently from thread=5Ffunc.

CU, Ingo

Other related posts: