Re: Suggestions needed for gtk frontend for cdebconf
Hi,
On Tue, Jun 10, 2003 at 02:49:15PM +0000, Sebastian Ley wrote:
>
> Bernhard R. Link schrieb:
>
> > What is the current way to get some program (like a shell) working? Is
> > it still the menu-items responsibility (like it was when I last looked
> > quite some time ago) or was the debconf-protocol extended to allow the
> > frontend to take the needed steps or was it even implemented an other
> > way?
>
> If a menu item is selected, the associated udeb's postinst is executed.
> This is where all action takes place.
>
> > > To display the log output in a gtk window, I came to the conclusion that I
> > > needed threads. If control goes to some udeb postinst which produces an
> > > error, the frontend code must be in control to actually display it
> > > (gtkmain).
> >
> > Does it really need multi-threading or would multi-tasking be enough?
>
> I don't see how spawning another process will help. Debconf calls the
> frontend when it wants something done by the user (or present something to
> him). This is when frontend code gets into control. What I need is, that it
> stays in control so that a terminal and an error output works permanently
> (not only when frontend code gets into control the next time). Since the
> frontend is part of cdebconf I do not know how else than threads should
> solve this.
/Hopefully/, you'll find another way, such as a simple terminal that
supplies two pseudo-ttys (or simply a pty and a pipe), one for the main
application, and one for a error/log output area.
But that is just one example. Please learn a bit about Unix' way of
dealing with open files and processes. The only practical difference
between processes and threads is that the latter share their address
space.
The problem you're trying to solve has likely nothing to do with the
need to have two threads of execution in the same address space, but
rather with multiplexing output to a terminal, or having multiple
virtual terminals on the same framebuffer.
I repeat: that has nothing to do with threads, and is easier to solve
with multiple processes (probably using one that sits in between the
real terminal and the processes, like screen(1)) than with threads.
On *nix, you don't spawn a process out of thin air, so the children
don't need to open a new channel for their terminal I/O themselves. The
parent *process* normally sets up the standard input and standard output
file descriptors. So, a terminal emulator can function as the parent for
a 'tail -f' command and for the dpkg-udeb game at the same time, and
render the output of both to a framebuffer or VT.
And even in the terminal emulator you don't need to use threads, and
most sane programmers would avoid them for such a simple problem. You
have the select() call for this purpose, that wakes up your process if
there's anything happening on either pseudo terminal, i.e. if there's
any output from either child.
Please educate yourself about Unix before you enter the minefield of
multithreading, with its danger of races, resulting in programs that
loose al their deterministic qualities and work in 90 % of the cases,
mysteriously failing in others, that are virtually impossible to debug.
Unix has *proper* IPC and I/O multiplexing. Be glad that you don't need
multithreading as often as in Windows.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
Reply to: