Re: Glib::Dispatcher

[D. B.]

On Mon, Jan 23, 2017 at 12:00 PM,  wrote:

>
> Date: Mon, 23 Jan 2017 09:35:54 +0530
> From: Amit 
> To: gtkmm-list@gnome.org
> Subject: Re: gtkmm-list Digest, Vol 153, Issue 7 Gtkmm GUI fails to
> update
> Message-ID: <58858122.9000...@skanray.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
>
> Hi D. B .
>
> [...]
> *does it handle all calls to GTK++/mm functions?*
>
>   Pls Clarify  ...
>

I think I must've been thinking of something different. By reading
https://developer.gnome.org/gtkmm-tutorial/stable/sec-using-glib-dispatcher.html.en

it's hard to imagine any way to make non-threadsafe calls to GTK+ functions
using Dispatcher.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Best and esiest to implemet pthread , GLib::Thread , GLib::Dispatcher

[jonathon]

Have you considered simply using libsoup instead of libcurl? Libsoup can do 
async I/O integrated with the glib mainloop so that you won't need to use 
threads (in theory).

On 1/1/12 12:59 AM Kaiser . wrote:

Hello

I have made small gtkmm program that download some files from Internet by using 
libcurl..

But when the program start downloading the files it Freez until it finish (cuz 
of  single thread??)..

I knew that I must implement multi-threading to solve the problem ...

I have 3 classes in the program : WINDOW , APP , CURL

// here are some brief of the program
CURL contains CURLREAD function to download the files and some helper functions
APP contains other utils of program and contains getPKG() which get the URLS 
and download the files throught the object curl.curlread(url ,,,)
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://mail.gnome.org/mailman/listinfo/gtkmm-list

Best and esiest to implemet pthread , GLib::Thread , GLib::Dispatcher

[Kaiser .]

Hello

I have made small gtkmm program that download some files from Internet by using 
libcurl..

But when the program start downloading the files it Freez until it finish (cuz 
of  single thread??)..

I knew that I must implement multi-threading to solve the problem ...

I have 3 classes in the program : WINDOW , APP , CURL 

// here are some brief of the program
CURL contains CURLREAD function to download the files and some helper functions
APP contains other utils of program and contains getPKG() which get the URLS 
and download the files throught the object curl.curlread(url ,,,)
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://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Best and esiest to implemet pthread , GLib::Thread , GLib::Dispatcher

[Michael Moorman]

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 in 1 ( see 
http://developer.gnome.org/gtkmm-tutorial/3.2/sec-timeouts.html.en ). This can 
safely update anything on the GUI since it's invoked from 
the main loop. Update any GUI related things (progress bar, 
error/success indications, etc) using this function. 


Consider using a Glib::Mutex to facilitate safe communication between the two 
threads, i.e. synchronizing access to any shared buffer. 
Good luck!




 From: Kaiser . yahya...@hotmail.com
To: gtkmm-list@gnome.org 
Sent: Sunday, January 1, 2012 1:59 AM
Subject: Best and esiest to implemet pthread ,  GLib::Thread , GLib::Dispatcher
 

 
Hello

I have made small gtkmm program that download some files from Internet by 
using libcurl..

But when the program start downloading the files it Freez until it finish (cuz 
of  single thread??)..

I knew that I must implement multi-threading to solve the problem ...

I have 3 classes in the program : WINDOW , APP , CURL 

// here are some brief of the program
CURL contains CURLREAD function to download the files and some helper functions
APP contains other utils of program and contains getPKG() which get the URLS 
and download the files throught the object curl.curlread(url ,,,)
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://mail.gnome.org/mailman/listinfo/gtkmm-list


___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Glib::Dispatcher and data transfer into main loop

[Andreas Volz]

Am Sat, 19 Apr 2008 20:53:23 +0200 schrieb Ludwig Hähne:

 Hi Andreas,
 
 Andreas Volz wrote on 19.04.2008 17:37:
  Any ideas how to solve that problem? I've seen no way to give data
  to the dispatchSignal() call. So I need a member variable to
  transfer data from the thread called function to the dispatched
  function. I could think of a queue that saves all the incoming data
  from the thread for later use in the dispatched function. Do you
  think that's the best way to do it? Any other ideas?
 
 A queue protected with a (exception-safe) Mutex and a dispatcher is
 what I did in these cases:
 
 | Glib::Dispatcher dispatcher;
 | Glib::Mutex logMutex;
 | std::queue... pipe;
 
 Producer thread:
 
 | Glib::Mutex::Lock lock(logMutex);
 | pipe.push(ent);
 | lock.release();
 | dispatcher.emit();
 
 Consumer (main) thread:
 
 | Glib::Mutex::Lock lock(logMutex);
 | assert(pipe.empty() == false);
 | Entity ent = pipe.front();
 | pipe.pop();
 | return ent;

That's like what I thought of. It works for me. Thanks.

regards
Andreas
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Glib::Dispatcher and data transfer into main loop

[Andreas Volz]

Am Sat, 19 Apr 2008 20:33:43 +0200 schrieb klaus triendl:

 Andreas Volz schrieb:
  Hello,
  
  I'm using a Glib::Dispatcher to dispatch data from a thread into my
  main loop. This is my code:
 [snip]
  Any ideas how to solve that problem? I've seen no way to give data
  to the dispatchSignal() call. So I need a member variable to
  transfer data from the thread called function to the dispatched
  function. I could think of a queue that saves all the incoming data
  from the thread for later use in the dispatched function. Do you
  think that's the best way to do it? Any other ideas?
 
 Did you see my post a few days ago about interthread communication
 with sigx?
 The library would solve exactly your problem (and it does indeed put
 the incoming data into a message queue).
 cMan could create a signal to which other threads can connect. The 
 signal can have any number of parameters (up to sigc's arity).

Very interesting! The sigx library seems to be very young. Is it yet
tested on win32?

regards
Andreas
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: GLib::Dispatcher with arguments

[Emil Nowak]

On 2007-03-12, at 18:45:03 Niko Demmel wrote:

 Is there a way to evoke a callback function in another thread and pass
 arguments to it?

 Alternatively I probably will have to program my own message queue...
libsigx seems to have functionality You are looking for. 
Check this:
http://libsigcx.sourceforge.net/docs/sigcx_starting.html
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: GLib::Dispatcher with arguments

[Niko Demmel]

 Is there a way to evoke a callback function in another thread and pass
 arguments to it?
 
 libsigx seems to have functionality You are looking for. 
 Check this:
 http://libsigcx.sourceforge.net/docs/sigcx_starting.html
Yes it seems. I'll have a closer look at it. Thanks for the tip.

It's just that i've tried building libsigcx before and you can't under
windows (wihtout cygwin) as it uses unix socket stuff. I'll probably
have to use cygwin then...
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

GLib::Dispatcher with arguments

[Niko Demmel]

Is there a way to evoke a callback function in another thread and pass
arguments to it?

Something like a Dispatcher that connects to a slotvoid, int?

Alternatively I probably will have to program my own message queue...

Regards
Niko
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Glib::Dispatcher: How to use a non-void signal for tunneling?

[Vinzenz 'evilissimo' Feenstra]

hmm, I am not sure if you're looking for somthing like Glib::Cond

http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1Cond.html

Have a look at the example. Maybe it is what you're looking for.

BR
Vinzenz 'evilissimo' Feenstra

Matthias Kaeppler schrieb:


Hi Vinzenz,

thanks for the material, much appreciated, I'll give it a shot asap 
(since I happen to be from Germany, it's not even a language issue).


Meanwhile, I managed to get everything to work by intercepting the 
object in question on each progress-update and copy all the data I 
need over to the dialog, such that it's still valid after dispatching 
the cross-thread GUI-update (that was not the case with the info 
object, that's why my code segfaulted).


I'd have another quick question though if you don't mind; it's more of 
a general question and does not relate to an error in my code or so:


My problem is that I'm not quite sure /when/ I have to dispatch a 
call. The case with the dialog was pretty clear, because I had to 
modify its interface (e.g. move the progress bar, set new text etc.), 
and these actions included direct modification of the GUI.


But what about this:

In the non-GUI thread a signal handler is called by the async transfer 
method. In this signal handler I check in which phase the transfer is, 
etc. At some point I spawn the transfer dialog using Dialog::show() 
and at some other point I hide it when the transfer has finished.
I am /not/ dispatching these calls; but since these calls invalidate 
parts of the main window (the area where the dialog appears has to be 
redrawn of course), maybe I should do that? IOW, I am calling show() 
and hide() directly from the non-GUI thread. For now, I found it 
overly complicating my code to introduce another dispatcher just to 
dispatch calls to show() and hide()!


For now, I haven't had any trouble with that, but wouldn't these two 
calls strictly speaking have to occur in the GUI thread? How can I see 
which calls classify themselves to be absolutely necessary to be 
called from the GUI thread and which don't? The documentation is not 
clear in that point.


Any clarification appreciated.

Best regards,
Matthias



___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Glib::Dispatcher (multiple emit/write lockup)

[Chris Vine]

On Tuesday 28 June 2005 04:15, Mario Sergio Fujikawa Ferreira wrote:

[snip]

 I added a few fprintf(stderr, ) traces to glibmm dispatch.cc
 code so that I could pin point exactly where the problem occured. It
 seems to me that it is a problem with reentrancy since nothing
 guarantees that the write(2) call on the sender is atomic.

  Which is reinforced by the comment right below the write(2)
 call on the DispatchNotifier::send_notification() method on

 http://cvs.gnome.org/viewcvs/glibmm/glib/glibmm/dispatcher.cc?rev=1.12view
=markup

 // All data must be written in a single call to write(), otherwise we
 can't
 // guarantee reentrancy since another thread might be scheduled between
 two
 // write() calls.  The manpage is a bit unclear about this -- but I hope
 // it's safe to assume immediate success for the tiny amount of data
 we're
 // writing.

  Well, I am hitting a wall here. Glib::Dispatcher is not
 reentrant and there is little I can do about it.
 Adding per Dispatcher mutex protections around the write(2) system call
 do-while loop

while (sender_mutex_.trylock() == false)
  Glib::Thread::yield();

do
  n_written = write(fd_sender_, data, sizeof(data));
while(n_written  0  errno == EINTR);

sender_mutex_.unlock();

 does not protect against lockups. Nor does adding a mutex inside
 Dispatcher::emit().

 void Dispatcher::emit()
 {
Glib::Mutex::Lock lock_(mutex);
notifier_-send_notification(this);
 }

  Checking the mailing lists, I found some interesting remarks

 http://mail.gnome.org/archives/gtkmm-list/2002-September/msg0.html

 which do point out the reentrancy problem.

  There is a suggested solution at

 http://mail.gnome.org/archives/gtkmm-list/2002-September/msg8.html

 pointing out that a lock-free FIFO multiple-writers-single-reader could
 be the solution. I do agree that this is non trivial.

The POSIX Single Unix Specification provides in relation to write() that:

Write requests to a pipe or FIFO shall be handled in the same way as a 
regular file with the following exceptions:

  ...

  Write requests of {PIPE_BUF} bytes or less shall not be interleaved with
  data from other processes doing writes on the same pipe. Writes of greater
  than {PIPE_BUF} bytes may have data interleaved, on arbitrary boundaries,
  with writes by other processes, whether or not the O_NONBLOCK flag of the
  file status flags is set.

  ...

PIPE_BUF is never less than 512 and is usually 2048 in size.  Admittedly the 
standard only requires writes by different processes to be atomic with a 
write of a size not greater than that, but it would be odd if the same 
behaviour were not exhibited by different threads within one process.  If you 
are using Windows, I thought that it was POSIX compliant?

Unfortunaly gnome.org is down at the moment so I cannot look up your mailing 
list references, but why is it that mutexes around the write call don't solve 
the issue (if in fact different threads within the same process do not 
benefit from the POSIX atomicity guarantees)?  That should avoid concurrent 
writes to the Dispatcher pipe in every case.

Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Glib::Dispatcher (multiple emit/write lockup)

[Mario Sergio Fujikawa Ferreira]

Hi,

	I have an application running multiple threads and making heavy  
use of dispatchers. The application seemed to lock up erractically.


$ kill -11 app_id
$ gdb app core

Doing some gdb back tracing, it all traced back to dispatch emit() then
to the write(2) system call.

	I added a few fprintf(stderr, ) traces to glibmm dispatch.cc  
code so that I could pin point exactly where the problem occured. It  
seems to me that it is a problem with reentrancy since nothing  
guarantees that the write(2) call on the sender is atomic.


Which is reinforced by the comment right below the write(2)
call on the DispatchNotifier::send_notification() method on

http://cvs.gnome.org/viewcvs/glibmm/glib/glibmm/dispatcher.cc?rev=1.12view=markup

// All data must be written in a single call to write(), otherwise we  
can't
// guarantee reentrancy since another thread might be scheduled between  
two

// write() calls.  The manpage is a bit unclear about this -- but I hope
// it's safe to assume immediate success for the tiny amount of data  
we're

// writing.

	Well, I am hitting a wall here. Glib::Dispatcher is not  
reentrant and there is little I can do about it.
Adding per Dispatcher mutex protections around the write(2) system call  
do-while loop


  while (sender_mutex_.trylock() == false)
Glib::Thread::yield();

  do
n_written = write(fd_sender_, data, sizeof(data));
  while(n_written  0  errno == EINTR);

  sender_mutex_.unlock();

does not protect against lockups. Nor does adding a mutex inside  
Dispatcher::emit().


void Dispatcher::emit()
{
  Glib::Mutex::Lock lock_(mutex);
  notifier_-send_notification(this);
}

Checking the mailing lists, I found some interesting remarks

http://mail.gnome.org/archives/gtkmm-list/2002-September/msg0.html

which do point out the reentrancy problem.

There is a suggested solution at

http://mail.gnome.org/archives/gtkmm-list/2002-September/msg8.html

pointing out that a lock-free FIFO multiple-writers-single-reader could  
be the solution. I do agree that this is non trivial.


	Has anyone worked on such a solution? I did a very ugly work  
around in the mean time.


void Dispatcher::emit()
{
  Glib::usleep(1000);
  notifier_-send_notification(this);
}

I'll probably add a rand addition to that to avoid timed
collisions. However, this is an undesirable at best. :)

Any takers?

___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list