should implement pthread , GLib::Thread or GLib::Dispatcher ?!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
,,,)
Window has progressBAR
CURL is object on APP and APP is object on WINDOW
which one I should implement pthread , GLib::Thread or GLib::Dispatcher ?!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http
Hi Kaiser,
This one way I would approach this problem.
1. Launch a GLib::Thread to download the files. The API is quite nice and easy
to use.
2. Register a timeout function on the main gtk loop that periodically
checks (maybe once every half second) on the status of the thread you
launched
into a Glib:: mutex, although in principle there
shouldn't be any problem in using a std:: mutex to wake up a Glib::
thread, or vice versa. (This may depend on the specific
implementation of the library you use.)
It's also possible that one or the other have particular per-thread
init or cleanup
On Sun, 16 Oct 2011 23:35:07 +0100
Chris Gordon-Smith c.gordonsm...@gmail.com wrote:
Hello Chris
Thanks for this. Yes - I've used Glib::Dispatcher, thanks to a large
degree to your posting to this list back in March!
I have used Glib::Thread to give myself a GUI Thread and a simulation
On Mon, 2011-10-17 at 21:57 +0100, Chris Gordon-Smith wrote:
Thanks. This makes sense to me. I agree that Glib should eventually
drop its own threading implemention. As things stand now, the
requirement for GTKmm programmers to use Glib::Thread impedes the
adoption of the standard - std
On Mon, 17 Oct 2011 21:57:00 +0100
Chris Gordon-Smith c.gordonsm...@gmail.com wrote:
[snip]
So the way ahead for my project is:-
* Continue using Glib::Thread and Glib::Dispatcher to keep two
separate Glib threads in my program - one for the GUI and one for
the simulation
programmers to use Glib::Thread impedes the
adoption of the standard - std::thread.
Then this is something that someone should talk to the glib developers
about.
Glib::Thread doesn't impede the use of std::thread or C threads, and it
now appears that there is now no intention to do so
if
using glib 2.32, in order to make glib thread safe, and use
Glib::Dispatcher for inter-thread communication, and you are ready
to go.
Hmmm. Are you saying that instead of calling Glib::Thread::create, I
could call the equivalent for std::thread? If feasible, it would be a
definite
On Mon, 17 Oct 2011 23:40:01 +0100
Chris Gordon-Smith c.gordonsm...@gmail.com wrote:
[snip]
Hmmm. Are you saying that instead of calling Glib::Thread::create, I
could call the equivalent for std::thread? If feasible, it would be a
definite improvement over what I am currently doing.
Yes
there shouldn't be any problem in using a std::
mutex to wake up a Glib:: thread, or vice versa. (This may depend on the
specific implementation of the library you use.)
It's also possible that one or the other have particular per-thread init or
cleanup requirements which won't be met by the other (I
Hello All
I have recently introduced multi-threading into my artificial chemistry
simulator, so that the GUI can be active while the simulation is
running.
To do this, I've used Glib::Thread. Now that C++11 provides threading
with std::thread, I would prefer to use that. Is it possible to use
Hi Chris,
From experience: Of course it is, if you 1. mutex critical sections or 2.
lock-free ringbuffer all events between the threads, there's
no reason you can't use 2 (or more) different types of threads in one app.
From a practical point of view, why would you? Glib::Thread should
to a small section of code, but I would have preferred not to
do this at all.
My question is: Could I have avoided use of Glib::Thread altogether, and
just used std::thread?
I think probably not, but thought I would ask.
Chris Gordon-Smith
www.simsoup.info
On Sun, 2011-10-16 at 17:44 +0100, Harry van
ringbuffer all events between the threads, there's
no reason you can't use 2 (or more) different types of threads in
one app.
From a practical point of view, why would you? Glib::Thread should
suffice for simulator / GUI separation...
Perhaps I'm not following your use-case, or maybe
wrapper classes to limit the scope of the
dependency to a small section of code, but I would have preferred not to
do this at all.
My question is: Could I have avoided use of Glib::Thread altogether, and
just used std::thread?
I think probably not, but thought I would ask.
Chris Gordon
, but I would
have preferred not to
do this at all.
My question is: Could I have avoided use of
Glib::Thread altogether, and
just used std::thread?
I think
On Sun, 16 Oct 2011 19:44:53 +0100
Chris Gordon-Smith c.gordonsm...@gmail.com wrote:
My question is: Could I have avoided use of Glib::Thread altogether,
and just used std::thread?
You can use C++11 threads fine with glib/glibmm, because the C++
standard library will almost certainly use
Hello Chris
Thanks for this. Yes - I've used Glib::Dispatcher, thanks to a large
degree to your posting to this list back in March!
I have used Glib::Thread to give myself a GUI Thread and a simulation
thread, so that my GUI remains active even while the simulation is
running. I now have
2010/6/8 Adam Chyla [PL] adam.ch...@gmail.com:
Hi.
I'm trying to run my program with one thread. Only window is not responding,
theards still works. I don;t known what is wrong.
I think the problem is that you are trying to modify the label from a
different thread than the one that created
Hi.
I'm trying to run my program with one thread. Only window is not responding,
theards still works. I don;t known what is wrong.
Please look at this:
http://wstaw.org/w/6z7/
http://wstaw.org/w/6z8/
There is a code:
http://svn2.xp-dev.com/svn/bandyta/
When I run my code with
the
relevant trackable_callback from the list by calling
std::listsigc::trackable_callback::erase().
If (see [1] below) slots do behave in this way, it would follow that
thread creation in glibmm using Glib::Thread::create() is not thread
safe where the callback invoked is a non-static method of a class
Hi,
i would like to pass an argument (a pointer) to a thread (using
Glib::Thread::create).
In the class reference there is mentioned that i can do this using sigc::bind()
Has anybody a short example for me how to do this or a link to an example?
I'm working under windows and use Glibmm 2.4
On 29/04/2007 14:40, Norbert Bauer wrote:
i would like to pass an argument (a pointer) to a thread (using
Glib::Thread::create).
In the class reference there is mentioned that i can do this using
sigc::bind()
Has anybody a short example for me how to do this or a link to an example?
I'm
Am Donnerstag, den 18.01.2007, 19:14 +0100 schrieb Daniel Elstner:
Am Donnerstag, den 18.01.2007, 18:34 +0100 schrieb Andreas Volz:
Ok, is there a way to find out the Glib thread model at runtime and/or
compile time?
Well, unless you implement your own backend (Glib::thread_init() takes
Am Wed, 17 Jan 2007 19:54:22 +0100 schrieb Daniel Elstner:
Am Mittwoch, den 17.01.2007, 19:43 +0100 schrieb Andreas Volz:
Hello,
is it possible to mix the use of Glib::Thread and the C pthread_*
API? The problem is that I use an API (gpsd) that needs a pthread_t
as argument. In my
Am Donnerstag, den 18.01.2007, 18:34 +0100 schrieb Andreas Volz:
Is Glib::Thread always implemented with pthreads? Also on the win32
plattform? Do I get problem while porting my application to win32?
Likely, yes. Though pthreads are probably more or less supported on
Cygwin, you'll
Hello,
is it possible to mix the use of Glib::Thread and the C pthread_* API?
The problem is that I use an API (gpsd) that needs a pthread_t as
argument. In my application I have yet several Glib::Thread's. Are their
potential problems by mixing both models?
Is Glib::Thread always implemented
Am Mittwoch, den 17.01.2007, 19:43 +0100 schrieb Andreas Volz:
Hello,
is it possible to mix the use of Glib::Thread and the C pthread_* API?
The problem is that I use an API (gpsd) that needs a pthread_t as
argument. In my application I have yet several Glib::Thread's. Are their
potential
Alexander [EMAIL PROTECTED] wrote:
Hi everybody!
I need to have more than one window in program, working
at the same time. In Main window I have table with windows title,
address for manipulation with windows.
I use Glib::Thread to create threads for new window:
Main_Window::Main_Window
Strange behavior of Gtk::Main::run().
when I wrote:
void Main_Window::on_Show_clicked() /*button signal_clicked()*/
{
Gtk::Window wnd;
Gtk::Main::run(wnd);
}
it work OK. Every time when I press button method
create new window.
But when I connect() this method to
Gtk::ActionGroup and
Hi everybody!
I need to have more than one window in program, working
at the same time. In Main window I have table with windows title,
address for manipulation with windows.
I use Glib::Thread to create threads for new window:
Main_Window::Main_Window()
{
Glib::thread_init
:
i call throw Glib::Thread::Exit() to exit from a thread,
what happens is:
glibmm-ERROR **:
unhandled exception (type unknown) in signal handler
aborting...
this happens to me on every program i wrote that uses glib's threads
I have never thrown that exception to exit a thread and I
environmental
variable exported:
LD_ASSUME_KERNEL=2.4.19
In Redhat and Suse at least this forces NPTL to adopt Linuxthreads behaviour
(that is, it prevents forced stack unwinding) and it probably does the same
with your distribution, so if Glib::Thread::Exit works correctly with this
variable set
i call throw Glib::Thread::Exit() to exit from a thread,
what happens is:
glibmm-ERROR **:
unhandled exception (type unknown) in signal handler
aborting...
this happens to me on every program i wrote that uses glib's threads
yair
___
gtkmm-list
On Saturday 25 June 2005 12:58, Yair Hershkovitz wrote:
i call throw Glib::Thread::Exit() to exit from a thread,
what happens is:
glibmm-ERROR **:
unhandled exception (type unknown) in signal handler
aborting...
this happens to me on every program i wrote that uses glib's threads
I
36 matches
Mail list logo
