Re: [gtkmm] progress bar headache
- From: Chris Vine <chris cvine freeserve co uk>
- To: gtkmm-list gnome org
- Cc: Alberto Paro <alberto paro homeunix org>
- Subject: Re: [gtkmm] progress bar headache
- Date: Thu, 6 May 2004 22:44:33 +0100
On Thursday 06 May 2004 07:57, Alberto Paro wrote:
> junk siology net wrote:
> | lo, ive got this code.....
> | ive got a timeout event which makes a progress bar pulse() no
> | problem at all, the idea is that let_progress_go (boolean) if true
> | will allow the pulse command to happen, if not it will skip it (i
> | used an if statement for that) -- still no trouble.
> | the problem is that the progress bar isnt started during this block
> | of code, (when i set let_progress_g to true). and even if i put the
> | pulse() call directly in the loop at point A it dosnt work.
> Popen locks the interface.
> You have to thread the md5 operation. Look at some past message thread
> to thread and interface update.
Or if the OP is writing a non-threaded (or more accurately uni-threaded)
application and can avoid having to use fgets() for C string input (that is,
he can make do with reading into a buffer array and obtaining formatted
output from that), he can just use a main loop event handler (ie, use the
normal pipe(), fork() and exec*() approach, make the read pipe file
descriptor non-blocking with fcntl(), and then plumb it into the main loop by
connecting it to an event handler with Glib::signal_io().connect()).
Depending on what he is trying to do this could be easier than employing
threading. For example, if his program needs to launch other programs with a
fork() and exec*() call, IEEE POSIX Std 1003.1 requires that in a
multi-threaded program all system calls between the fork() and exec() calls
are async-signal-safe. No such requirement is imposed in a single threaded
] [Thread Prev