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 [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
