Re: Embedded QT architecture issues (was Re: [linuxce-devel] Re: [iPAQ] Embedded QT on iPaq?)

On Tue, 14 Nov 2000 23:18, Jay Carlson wrote:
> Martin Jones wrote:
> > On Tue, 14 Nov 2000 13:02, Jay Carlson wrote:
> >> Nils Faerber wrote:
> >>> On Mon, 13 Nov 2000, Tom_Kirksey_at_ingersoll-rand.com wrote:

[snip - getting out of hand]

> >>>
> >>> Sure but the non-coexistance with other toolkits makes it a no-go for
> >>> me.
> >
> > How many different toolkits would you want to run on an embedded
> > device? In practice you will choose one toolkit for your device
> > and stick with it.
>
> I think it depends on who you are, what you want to do, and how big the
> device is. Not everyone is going to be a device vendor or distribution
> creator. Some Squeak users will be hardcore enough to want to run
> directly on fb. Same may be true of kaffe.

Sure, different strokes for different folks.

[snip again]

> >
> >> Running in one big process under Unix seems...unthemely, somehow.
> >
> > Not necessary as I mentioned, but its nice to have the option.
>
> Yeah. I'm trying to get my head around all the issues here. How about
> this:
>
> In a perfect world, there should not be much difference in memory and
> disk usage between (say) multiple QTE processes and the same
> functionality wrapped up in a unified app. C and C++ applications can
> usually do pretty well at this, as vast amounts of time have been spent
> getting the mechanisms for space sharing (shared libraries,
> copy-on-write demand loading, appropriate ABIs) right, and C programmers
> are used to the restrictions that those mechanisms impose.
>
> One effect of these mechanisms is to obscure actual resource
> utilization. In a naive model, each process is charged for its combined
> ..text/.data/brk and that of all the libraries it uses. But we "know"
> that the bulk of libc is shared across all processes, so we only charge
> 1/N of libc's .text to each process using it.
>
> Well, actually we'd like to charge based on the amount of .text paged
> in. Run-once initialization code can be dropped by the kernel mm after
> its use; error-handling code that's never used won't enter RAM unless
> it's on the same page as active code. (Does anyone know of a way of
> asking the kernel, "what parts of this file are paged in?")
>
> Even that model isn't right, as applications may keep different parts of
> libc's .text "hot" and paged in; it's not fair to charge /bin/init for
> all those i18n functions the editor is using.
>
> Mechanisms for space sharing between processes generally have not been
> used in non-C environments on Unix. That's why one-big-process is so
> attractive for them.
>
> Let's pick on Tcl for a minute. The core interpreter and fixed types in
> Tcl are sharable, as they're implemented in C. Anything you load after
> startup isn't. Compiled Tcl code and data ends up in non-shareable
> heap. So the obvious first step is to "freeze" a memory image of that
> code once loaded and throw it in .data of a .so. I forget the details
> of how the current Tcl allocator works, but if it's doing inline
> reference counting or garbage collection, it will write to some of those
> pages, forcing a copy for each process. So you fix the allocator not to
> do that, and find other issues etc etc etc.
>
> I don't think this situation is hopeless, but I think it's clear that
> much work has already been done on the C runtime environment to make it
> many-process friendly. C programmers are willing to work with the
> runtime too, carefully const'ing data into .text.

Well, you've covered the low level details, but there are other
issues that the toolkits/librarys impose also. In the case of Qt
I am thinking of each application having its own QApplication. Its
not a huge overhead, but if you only need one GUI process, and you're
short on space, why waste it.

> >> I wrote up some of these issues (a while ago) at
> >> http://vhl-tools.sourceforge.net/issues.html ; perhaps it's a candidate
> >> to move to the handhelds swiki?
> >
> > In Qt/Embedded each application (process) accesses the framebuffer
> > directly. There is a master process, which can be any application,
> > that manages the display regions allocated to itself and each "client"
> > application, as well as input devices and IPC. The clients all agree
> > not to draw outside their allocated region (all this is transparent to
> > the programmer of course).
> >
> > I don't think this fits into any of the categories you mention on your
> > page.
>
> I agree. Can I steal your text for a writeup? The closest thing I have
> to this is a non-rendering window server, as each UI process has
> responsibility of getting its bits on screen.

Sure.

> How tightly tied to QTE are the child processes? Is it possible to
> reasonably build non-QTE apps that work as clients? Can children push

Sure, its possible. Nothing in the protocol is tied to Qt.
See qwscommand_qws.h and qwsevent_qws.h for a starting point.

> events---ie, can I run the input methods as a client? Or should I just

We don't at the moment but its trivial to add.

> go read the code and find out for myself? :-)

You can do that too :-)

-- 
Martin R. Jones
mjones_at_trolltech.com
Trolltech Australia