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

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

    OK guys! I've told you, in my experience, I've met quite few cases in
with I wanted to read data from 2+ sources. I thought when writing BWindow,
that BLooper isn't used that much, and proposed a solution. But, after
discussing with you, I realize that, indeed, there is no need to add
this extra functionality to BLooper. It's better spawning another thread,
read
the raw data, and send the results to a BLooper thread.
    I programmed a lot in the 8 years since I began, and also, I used
pooling, but now, because we are building an OS, things need to be done in
the best way possible and the OLD principles do not apply any more.
    Thanks for this lesson!

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

    Yeah! But the problem, here, is to use it when it's the case for it!
     :-) :-(

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

    No need to argue any more! :-)

>
> [...]
>
> > 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? In case no message arrives a read_port_etc() 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.

    Because a message could arrive at the 2nd port while waiting for the
1st.

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

    I stand now for letting BLooper unchanged!

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

    Yup! I think so too!

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

    Sir! Yes, Sir!

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

    It was a bad idea!

    OK! BLooper extension, is not a good idea!


    But, there is something that I want to talk about!

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

    Axel and I have talked about that. 5us is a very low value! It could've
just been "1"! The purpose is to be greater than 0, and not to big! For any
value >0 the thread is rescheduled and it will wait until the time passes,
but if the value is extremely low(like "5"), the thread will NEVER wait.
When
its turn comes, the thread will execute because it is certain that 5us have
passed since it has been rescheduled!

> 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_count() (mind you, the thread could have
> been preempted inbetween) it may even not need to be rescheduled.

    Hmm... not a good idea! I've told you, another message may have been
arrived at the 2nd port!

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

    This, I do not understand why! Both methods use pooling. Axel's
reschedules the thread is no message is waiting at the first port; mine,
checks all ports for messages, and if none, reschedules the thread!
    What am I missing?


Adi.

Other related posts: