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

> "Adi Oanca" wrote:
> > I'm ignoring the discussion before this thread, so...
> > Axel!?
>
> Hey, lazy bone! :-)
> Have a look at: http://www.freelists.org/archives/interfacekit/
>

    And see what? Emails that you've wrote without fully understanding what
I've wanted to say?!?
    I've told you I'll ignore the discussion from the previous threads! It
seems you do not want to! OK, then...

> I don't know how BWindow does that, but busy polling is not an option
> for the application kit's fundamental classes IMO.

    Like it or not, for the time being the fundamental class BWindow will
do that!

> I just got another "idea" - much better than snoozing for a while (and
> then checking the ports) would be to wait for a shorter amount of time
> on one port.

    Much better? Really? Look down for an explanation!

> Just snoozing would have many disadvantages, for example it could slow
> down message handling.

    How is this possible????? 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??? I would say that none is
better, they are equal!

> In my first mail, I suggested you to use another BLooper for this -
> while this would probably be the cleanest solution, it would create the
> need for two threads for just one window, which is too generous for a
> resource as limited as this.

    Very bad idea!

> To implement something like this, I would select the port where it is
> crucial to react quickly on messages, like incoming mouse positions, or
> whatever you prefer. When you got a message at that port, or the
> read_port_etc() function timed out, I would then check for messages on
> the other port with a timeout of zero.
>
> So it would look like this (in pseudo code):
>
> waitFor = reasonableAmountOfTime;
>
> while (isRunning) {
> status = read_port_etc(port1, B_RELATIVE_TIMEOUT, waitFor);
> if (status == B_OK)
> handlePort1();
>
> status = read_port_etc(port2, B_RELATIVE_TIMEOUT, 0);
> if (status == B_OK)
> handlePort2();
> }

    :)))) If you look in task_looper() that I've proposed, you will see
that those 2 methods are VERY much the same!

> Until we have wait_for_multiple_objects(), I think this is the cleanest
> solution we can come up with for a BWindow.

    Yup! Me too!

> I am not too fond towards that extension to BLooper.

    Neither am I! Your wait_for_multiple_objects() idea is MUCH BETTER!
Still... [read below!]

> 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!
    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_server is done through a shared memory area!!!
    I, as Ingo, do not see any other way of doing this, than pooling.

> so it's not urgently needed right now.

    No? 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!


> We own BLooper and BWindow, so we can just
> implement task_looper() two times, I wouldn't have any problems with
> that.

    I do! This is bad design!

> For the future, when we have something like the now often mentioned
> wait_for_multiple_objects(), I would prefer something like:
> BLooper::AddPort(port id);

    YES! It is a beautiful approach! Thought of that myself. But, I would
like something more general! As said, I would like to be able to read from
memory areas and serial ports!

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

Ingo wrote:
> > Just out of
> > curiousity, Axel, how much work do you think that will require in the
> > kernel?
>
> That would be interesting. Though, it wouldn't harm, if we don't have
> it for R1. We could do the polling thing for the time being and replace
> it as soon as the kernel provides the functionality.

    I fully agree!

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

> 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_looper() 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_looper(), so that it works optimally in all cases.

    YES!  I  TOTALLY agree!

> I would favor this approach over implementing (i.e. cloning and
> extending) task_looper() in all BLooper derived classes and needing to
> completely change them for R2.

    Right! Do not duplicate code! Long live OOP!

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!

> B_INFINITE_TIMEOUT if there is only one port to wait for, some other
> value if there are more.

    I do agree that, if there is only one port, B_INFINITE_TIMEOUT should be
used! Still...[read below]

> wait_for_multiple_objects()

    It is a very good idea!
        2 things that I REALLY want are:
    1) notification when a message arrived to a port
    2) notification when a change has been made to an area!!!

> Anyway, I think this call is a must, and it will become reality in R2,
> perhaps in addition to native async I/O - we'll see :-)

    Yes, Please!


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)? I've told you, without those extensions, very few will use BLooper as
a parent class!
    BTW, Axel, how can wait_for_multiple_objects() work for a serial port?

    Ohh, ... I almost forgot! What should we do if someone overrides
task_looper()? How can we make it quit?
    We should resolve this issue in R2 by making talk_looper() non-virtual
and adding a new class BThread. What do you think?


Adi.

Other related posts: