Re: watching a file descriptor in gtk3

[Chris Vine]

On Mon, 23 Jan 2017 18:10:46 -1000 (HST)
rbd  wrote:
> Eric (cecas...@aol.com) sent me the following earlier today in
> response to another discussion thread I started a few days ago re:
> GSubProcess:
> 
> > I put together a test example of GSubprocess. ...
> >
> > 
> > https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Pipes/gnuplot5.c
> >   
> 
> In an amazing bit of coincidence, Eric's example contains the
> following bit of code which would seem to have some bearing on this
> file descriptor watch discussion thread:
> 
> >  GSource
> > *source=g_pollable_input_stream_create_source((GPollableInputStream*)err_stream,
> >
> NULL);
> >  g_source_attach(source, NULL);
> >  g_source_set_callback(source, (GSourceFunc)read_err, NULL, NULL);  
> 
> Could this be yet another way to skin my cat? Perhaps better than the 
> GIOChannel, if not the g_source_add_unix_fd() solution? Looks like I
> could create my own GInputStream with
> 
>GInputStream *gis= g_unix_input_stream_new(mypipefd, FALSE);
> 
> and then use that stream (which should also be a
> GPollableInputStream, yes?) in the call to
> g_pollable_input_stream_create_source(). I had not intended to use
> stream (i.e., buffered) i/o, but there's probably no harm in doing
> so. This seems like a perspiration-free way to create the GSource I
> need.

I didn't know about that.  Yes, that looks as if it will do what you
want.  GInputStream is not buffered by the way.  GIO streams are based
on the class heirarchy of the java.io package, so for buffering you
would need to instantiate an object of the GBufferedInputStream type
(which is derived from GInputStream).  GPollableInputStream is an
interface which is implemented by any pollable GInputStream (which in
practice seems to mean any input stream for a device represented by a
file descriptor).

If you are not going to use any of the GInputStream methods to read
from the file descriptor that could be regarded as a somewhat heavy
weight way of doing it, but if it is convenient for you, why not, and
you could say something of the same for GIOChannel.  Given what you want
to do and what we now know to be your four options (GIOChannel,
GPollableInputStream, using g_source_add_unix_fd() directly or using
GPollFD directly) on reflection I think I would probably go for
GIOChannel for ease of use, but that is just a matter of impression.

Chris
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[rbd]

Eric (cecas...@aol.com) sent me the following earlier today in response to 
another discussion thread I started a few days ago re: GSubProcess:



I put together a test example of GSubprocess. ...


https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Pipes/gnuplot5.c


In an amazing bit of coincidence, Eric's example contains the following 
bit of code which would seem to have some bearing on this file descriptor 
watch discussion thread:


 GSource *source=g_pollable_input_stream_create_source((GPollableInputStream*)err_stream, 

NULL);

 g_source_attach(source, NULL);
 g_source_set_callback(source, (GSourceFunc)read_err, NULL, NULL);


Could this be yet another way to skin my cat? Perhaps better than the 
GIOChannel, if not the g_source_add_unix_fd() solution? Looks like I could 
create my own GInputStream with


  GInputStream *gis= g_unix_input_stream_new(mypipefd, FALSE);

and then use that stream (which should also be a GPollableInputStream, 
yes?) in the call to g_pollable_input_stream_create_source(). I had not 
intended to use stream (i.e., buffered) i/o, but there's probably no harm 
in doing so. This seems like a perspiration-free way to create the GSource 
I need.


Thanks doubly, Eric!

Roger

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[Chris Vine]

On Mon, 23 Jan 2017 22:18:19 +
Emmanuele Bassi  wrote:
> Hi;
> 
> On 23 January 2017 at 22:09, rbd  wrote:
> 
> >> It is not quite that bad.  The documentation for
> >> g_source_add_unix_fd() is inadequate, but although not immediately
> >> obvious the prepare, check and finalize handlers can in fact
> >> usually just be set to NULL (provided you have set the 'events'
> >> argument for g_source_add_unix_fd() correctly) so you only need to
> >> provide the dispatch handler, which executes your callback when an
> >> event occurs.
> >>
> >> The poor quality of the documentation is the real problem here.  I
> >> would give it a try and see how you get on with it.  
> >
> >
> > Nothing about the g_source_* functions is obvious from the official
> > docs, either immediately or otherwise! ;-> Seriously, one of the
> > least illuminated points there actually has to do with timeouts,
> > exactly where in the check->prepare->dispatch sequence the poll()
> > gets done, etc.  
> 
> Of course, patches and bugs for the documentation are welcome.
> 
> A good set of articles on GSource and the main context API in GLib is
> on Philip Withnall's blog; Philip actually contributed back that
> documentation in the API reference, but this kind of discussions on
> how the implementation works is ill-suited for an API documentation.
> 
> See:
> 
>   - https://tecnocode.co.uk/2014/03/27/what-is-gmaincontext/
>   - https://tecnocode.co.uk/2015/05/05/a-detailed-look-at-gsource/
>   -
> https://tecnocode.co.uk/2014/04/19/ensuring-functions-are-called-in-the-right-context/
> 
> The second article also covers your use case pretty accurately.

I don't want to appear argumentative, but the second article is not of
great assistance with respect to the OP's usage of a wrapper for poll()
which executes a callback in the glib main loop when a file descriptor
becomes available for reading - as the OP put it, a replacement for
XtAppAddInput().  For that (if not using GIOChannel) he needs
g_source_add_unix_fd(), NULL for the prepare, check and finalize
handlers and a dispatch handler which executes the callback and a type
derived from GSource which interfaces with that.  As far as I can see
there is little in the second article which explains that. (And I have
not seen any other article which does that either.)

The second article is concerned with a more complex implementation of a
non-file descriptor based event source.  For a file descriptor based
event source these days you just use g_source_add_unix_fd(), which does
most of the boiler plate for you, were one to know it.

Let me stress I am not being negative here.  I very much appreciate the
efforts of the glib developers.  But I have stubbed my toe on exactly
the same issue myself: having said that, setting up a few test cases
and reading the source code made it apparent fairly quickly how
g_source_add_unix_fd() actually works, and from there it was pretty
straightforward.

Chris
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[rbd]

Hi Emmanuele,

Thanks for the additional documentation references! They were generally 
informative, although I think the one you mentioned as being apropos of my 
particular case was actually designed to be used for a source specifically 
other than file descriptors -- it was useful nonetheless, however.


Roger


On Mon, 23 Jan 2017, Emmanuele Bassi wrote:


Hi;

On 23 January 2017 at 22:09, rbd  wrote:


It is not quite that bad.  The documentation for g_source_add_unix_fd()
is inadequate, but although not immediately obvious the prepare, check
and finalize handlers can in fact usually just be set to NULL (provided
you have set the 'events' argument for g_source_add_unix_fd()
correctly) so you only need to provide the dispatch handler, which
executes your callback when an event occurs.

The poor quality of the documentation is the real problem here.  I
would give it a try and see how you get on with it.



Nothing about the g_source_* functions is obvious from the official docs,
either immediately or otherwise! ;-> Seriously, one of the least illuminated
points there actually has to do with timeouts, exactly where in the
check->prepare->dispatch sequence the poll() gets done, etc.


Of course, patches and bugs for the documentation are welcome.

A good set of articles on GSource and the main context API in GLib is
on Philip Withnall's blog; Philip actually contributed back that
documentation in the API reference, but this kind of discussions on
how the implementation works is ill-suited for an API documentation.

See:

 - https://tecnocode.co.uk/2014/03/27/what-is-gmaincontext/
 - https://tecnocode.co.uk/2015/05/05/a-detailed-look-at-gsource/
 - 
https://tecnocode.co.uk/2014/04/19/ensuring-functions-are-called-in-the-right-context/

The second article also covers your use case pretty accurately.

Ciao,
Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[Emmanuele Bassi]

Hi;

On 23 January 2017 at 22:09, rbd  wrote:

>> It is not quite that bad.  The documentation for g_source_add_unix_fd()
>> is inadequate, but although not immediately obvious the prepare, check
>> and finalize handlers can in fact usually just be set to NULL (provided
>> you have set the 'events' argument for g_source_add_unix_fd()
>> correctly) so you only need to provide the dispatch handler, which
>> executes your callback when an event occurs.
>>
>> The poor quality of the documentation is the real problem here.  I
>> would give it a try and see how you get on with it.
>
>
> Nothing about the g_source_* functions is obvious from the official docs,
> either immediately or otherwise! ;-> Seriously, one of the least illuminated
> points there actually has to do with timeouts, exactly where in the
> check->prepare->dispatch sequence the poll() gets done, etc.

Of course, patches and bugs for the documentation are welcome.

A good set of articles on GSource and the main context API in GLib is
on Philip Withnall's blog; Philip actually contributed back that
documentation in the API reference, but this kind of discussions on
how the implementation works is ill-suited for an API documentation.

See:

  - https://tecnocode.co.uk/2014/03/27/what-is-gmaincontext/
  - https://tecnocode.co.uk/2015/05/05/a-detailed-look-at-gsource/
  - 
https://tecnocode.co.uk/2014/04/19/ensuring-functions-are-called-in-the-right-context/

The second article also covers your use case pretty accurately.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[rbd]

Thanks for all the further explication, Chris!


The problem is that the main loop would enter a busy loop.  Well, maybe
a 'busy-ish' loop.  If you call up g_idle_add() with a repeating
callback (one which returns TRUE) which does nothing except examine a
non-blocking select(), you will end up with one CPU core using
approximately 100% CPU.  The default idle priority
G_PRIORITY_DEFAULT_IDLE will put the idle event somewhat at the end of
the main loop's event queue, but when there is nothing else to do it
will continue executing it.  (On a multi-core system this might not be
immediately apparent - you need to be able to interpret top or whatever
other tool you use to see it.)

You could make this work with a timeout, say of around 50mS delay,
which puts the main loop to sleep for a while between iterations.


I hear you about the busyloop/timeout stuff. I have some familiarity with 
these issues from the ancient Xlib (and single-core/-CPU!) days, and 
appreciate your insight into how this impacts the glib/gtk mainloop.



It is not quite that bad.  The documentation for g_source_add_unix_fd()
is inadequate, but although not immediately obvious the prepare, check
and finalize handlers can in fact usually just be set to NULL (provided
you have set the 'events' argument for g_source_add_unix_fd()
correctly) so you only need to provide the dispatch handler, which
executes your callback when an event occurs.

The poor quality of the documentation is the real problem here.  I
would give it a try and see how you get on with it.


Nothing about the g_source_* functions is obvious from the official docs, 
either immediately or otherwise! ;-> Seriously, one of the least 
illuminated points there actually has to do with timeouts, exactly where 
in the check->prepare->dispatch sequence the poll() gets done, etc.



The GIOChannel interface is not well designed by today's standards.  It
confuses concerns by combining a wrapper for poll() with an object for
locale-based reading to and writing from files.  It is against modern
design practice to combine purposes in this way.  But it is old (it goes
back to GTK+-1.2 days) when large multi-purpose objects were all the
rage. We know better now.

Its naming is also now highly confusing as it is not related to glib's
gio namespace, which also provides numerous i/o functions, with an
emphasis on asynchronicity (but which unfortunately suffers from an
overly java-like approach to its stream objects - it may also be a
victim of its times).


Interesting history. Mixed-purpose utilities are a bit off-putting, but 
reliability and amount of available, easily understandable documentation 
go quite a long ways towards putting them back on again! My input is 
binary so I'd be turning off the encoding (and probably buffering) stuff 
anyway.


Thanks again for all your help!

Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[Chris Vine]

On Mon, 23 Jan 2017 09:30:17 -1000 (HST)
rbd  wrote:
> Hi Chris,
> 
> Thanks very much for all of that information -- it was very helpful!
> 
> >> I do not fully understand your question (especially I don't
> >> understand your reference to using "g_idle_add_full() and do my
> >> own non-blocking select() inside my callback", which would not
> >> work), ...  
> 
> I won't be trying the above approach unless all else fails (see
> below), but I am curious as to why you say that I could not
> successfully call a non-blocking select() (or poll(), if you prefer)
> on my file descriptor of interest inside a callback registered via
> g_idle_add_full(), then read from that descriptor if select() tells
> me there's something there. This is not as logically sensible as
> registering a separate input source to be polled inside the main
> loop, but I can't see why it wouldn't work.

The problem is that the main loop would enter a busy loop.  Well, maybe
a 'busy-ish' loop.  If you call up g_idle_add() with a repeating
callback (one which returns TRUE) which does nothing except examine a
non-blocking select(), you will end up with one CPU core using
approximately 100% CPU.  The default idle priority
G_PRIORITY_DEFAULT_IDLE will put the idle event somewhat at the end of
the main loop's event queue, but when there is nothing else to do it
will continue executing it.  (On a multi-core system this might not be
immediately apparent - you need to be able to interpret top or whatever
other tool you use to see it.)

You could make this work with a timeout, say of around 50mS delay,
which puts the main loop to sleep for a while between iterations.

> >> ... This may (or may not) help:
> >>   
> https://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/io_$
> 
> Thanks very much for the above code sample -- unfortunately it
> confirms my very worst expectations of what might be involved with
> using g_source_add_unix_fd(), etc., to monitor a file descriptor,
> i.e., create a new GSource, code up a whole set of GSourceFuncs
> routines to implement a process which is not well-described in the
> docs, etc. I'm clearly barking up the wrong tree on that!

It is not quite that bad.  The documentation for g_source_add_unix_fd()
is inadequate, but although not immediately obvious the prepare, check
and finalize handlers can in fact usually just be set to NULL (provided
you have set the 'events' argument for g_source_add_unix_fd()
correctly) so you only need to provide the dispatch handler, which
executes your callback when an event occurs.

The poor quality of the documentation is the real problem here.  I
would give it a try and see how you get on with it.
 
> >> ...
> >>   
> https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-add-watch
> >
> > By the way, if you are thinking of using GIOChannel, you might also
> > want to look at the implementation of gdk_input_add() and
> > gdk_input_add_full() in gtk+-2. Although now deprecated in gtk+-2,
> > you can still use those functions if you happen to be building
> > against gtk+-2.  
> 
> Using gtk3, not 2.
> 
> >
> > If you are using gtk+3 you can set up a read watch as follows (I
> > have not done a test compile on this snippet but it is what I have
> > on occasions done in the past, and it avoids keeping an explicit
> > GIOChannel object in scope if you only want to execute a callback
> > when a descriptor is ready for input - you can use the internal
> > reference counting to control channel lifetime):
> >
> >
> > guint start_read_watch(int fd, GIOFunc func) {
> >  GIOChannel *channel = g_io_channel_unix_new(fd);
> >  guint id = g_io_add_watch(channel,
> >G_IO_IN | G_IO_HUP | G_IO_ERR,
> >func,
> >NULL);  
> 
> GIOChannel is the ticket, I think, thanks for pointing me there
> (where I would probably have never gotten on my own)! Unlike 
> g_source_add_unix_fd(), of which I could find no useful example code 
> whatsoever other than the code you sent me, there seem to be a fair
> number of examples around on basic use of GIOChannel to more or less
> do what I want to do (I hope). This 2005 Robert Love article in
> particular was quite useful:
> 
> http://www.linuxjournal.com/node/8545/print
> 
> Still not as drop-dead simple as libXt/Motif's XtAppAddInput() (and I 
> cannot believe that I am actually favorably comparing Motif to any 
> more contemporary API whatsoever ;-> ), but simple enough to be
> useful.

The GIOChannel interface is not well designed by today's standards.  It
confuses concerns by combining a wrapper for poll() with an object for
locale-based reading to and writing from files.  It is against modern
design practice to combine purposes in this way.  But it is old (it goes
back to GTK+-1.2 days) when large multi-purpose objects were all the
rage. We know better now.

Its naming is also now highly confusing as it is not related to glib's

Re: watching a file descriptor in gtk3

[rbd]

Hi Chris,

Thanks very much for all of that information -- it was very helpful!


I do not fully understand your question (especially I don't understand
your reference to using "g_idle_add_full() and do my own non-blocking
select() inside my callback", which would not work), ...


I won't be trying the above approach unless all else fails (see below), 
but I am curious as to why you say that I could not successfully call a 
non-blocking select() (or poll(), if you prefer) on my file descriptor of 
interest inside a callback registered via g_idle_add_full(), then read 
from that descriptor if select() tells me there's something there. This is 
not as logically sensible as registering a separate input source to be 
polled inside the main loop, but I can't see why it wouldn't work.



... This may (or may not) help:


https://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/io_$

Thanks very much for the above code sample -- unfortunately it confirms my 
very worst expectations of what might be involved with using 
g_source_add_unix_fd(), etc., to monitor a file descriptor, i.e., create a 
new GSource, code up a whole set of GSourceFuncs routines to implement a 
process which is not well-described in the docs, etc. I'm clearly barking 
up the wrong tree on that!



...


https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-add-watch


By the way, if you are thinking of using GIOChannel, you might also want
to look at the implementation of gdk_input_add() and
gdk_input_add_full() in gtk+-2. Although now deprecated in gtk+-2, you
can still use those functions if you happen to be building against
gtk+-2.


Using gtk3, not 2.



If you are using gtk+3 you can set up a read watch as follows (I have
not done a test compile on this snippet but it is what I have on
occasions done in the past, and it avoids keeping an explicit GIOChannel
object in scope if you only want to execute a callback when a
descriptor is ready for input - you can use the internal reference
counting to control channel lifetime):


guint start_read_watch(int fd, GIOFunc func) {
 GIOChannel *channel = g_io_channel_unix_new(fd);
 guint id = g_io_add_watch(channel,
   G_IO_IN | G_IO_HUP | G_IO_ERR,
   func,
   NULL);


GIOChannel is the ticket, I think, thanks for pointing me there (where I 
would probably have never gotten on my own)! Unlike 
g_source_add_unix_fd(), of which I could find no useful example code 
whatsoever other than the code you sent me, there seem to be a fair number 
of examples around on basic use of GIOChannel to more or less do what I 
want to do (I hope). This 2005 Robert Love article in particular was quite 
useful:


http://www.linuxjournal.com/node/8545/print

Still not as drop-dead simple as libXt/Motif's XtAppAddInput() (and I 
cannot believe that I am actually favorably comparing Motif to any 
more contemporary API whatsoever ;-> ), but simple enough to be useful.


Thanks a bunch again, Chris!

Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[Eric Cashon via gtk-app-devel-list]

 
Hi Roger,

I put together a test example of GSubprocess. It starts Gnuplot, sets up the 
pipes and callbacks, and then when Gnuplot is done it opens the graph in an 
image widget. The GSubprocess will take care of the file descripters for you. 
Also, if I run valgrind with multiple plots being created it doesn't leak 
memory over time. It looks like the subprocess holds everything you need and 
when it is unreferenced everything gets cleaned up. If you want to just run one 
plot, comment out the plot_data() function in the subprocess finish callback. 
Also to get an error back to the program you can do something like changing 
"set ylabel" to "et ylabel" or something of the sort. Change things around to 
get an idea of how they work.

https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Pipes/gnuplot5.c

This might not be what you are looking for since it is a little higher level 
than using a spawn function but there are a lot of things set up with 
GSubprocess that make it worth consideration. Options. You can do some nice 
plotting with GTK+ and Gnuplot also.

Eric 

 

 



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[Chris Vine]

On Mon, 23 Jan 2017 00:29:46 +
Chris Vine  wrote:
[snip]
> I do not fully understand your question (especially I don't understand
> your reference to using "g_idle_add_full() and do my own non-blocking
> select() inside my callback", which would not work), but you can
> either use glib's g_poll()/g_source_add_poll() implementation or (on
> unix) its g_source_add_unix_fd() implementation to watch on a file
> descriptor. The functionality of both is equivalent, and on unix both
> use poll() underneath. This may (or may not) help:
> 
> https://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/io_watch.cpp
> 
> If you want to use glib's g_source_add_poll() implementation rather
> than its g_source_add_unix_fd() implementation, you can avoid some of
> the boiler plate with g_io_add_watch() - you can use this to call up a
> callback function whenever a file descriptor is ready (you don't need
> to use the GIOChannel object for any other purpose, such as reading
> from or writing to the descriptor):
> 
> https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-add-watch

By the way, if you are thinking of using GIOChannel, you might also want
to look at the implementation of gdk_input_add() and
gdk_input_add_full() in gtk+-2.  Although now deprecated in gtk+-2, you
can still use those functions if you happen to be building against
gtk+-2.

If you are using gtk+3 you can set up a read watch as follows (I have
not done a test compile on this snippet but it is what I have on
occasions done in the past, and it avoids keeping an explicit GIOChannel
object in scope if you only want to execute a callback when a
descriptor is ready for input - you can use the internal reference
counting to control channel lifetime):

guint start_read_watch(int fd, GIOFunc func) {
  GIOChannel *channel = g_io_channel_unix_new(fd);
  guint id = g_io_add_watch(channel,
G_IO_IN | G_IO_HUP | G_IO_ERR,
func,
NULL);
  /*
 The call to g_io_add_watch incremented the channel's reference
 count.  Decrement the count now so that when func returns FALSE
 or g_source_remove() is applied to the returned id, the channel
 object will automatically be destroyed.
  */
  g_io_channel_unref(channel);
  return id;
}

This will not close the file descriptor when the watch has finished
(but see g_io_channel_set_close_on_unref()).

g_source_add_unix_fd() may be more efficient if you have a large number
of file watches in any one program.

Chris
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[Chris Vine]

On Sun, 22 Jan 2017 11:05:41 -1000 (HST)
rbd  wrote:
> Hi all,
> 
> I need to monitor a Unix file descriptor for input within my gtk3
> program. I believe that I need to somehow be using
> g_source_add_unix_fd() and friends but am finding the documentation
> confusing. Are there any simple examples which show how to do this
> anywhere? (I looked but could not find, apologies for any oversight
> on my part.)
> 
> I am porting an old Motif app which used
> 
>  XtAppAddInput( ... fd ... callbackproc ...)
> 
> to register an input handler callbackproc() to be called whenever
> there was input pending on fd. Whatever I use to replace this should
> NOT block for any user-perceivable amount of time when checking fd
> for pending input, which will typically be very small (under 80
> bytes) and occurring between a few times per second and a few times
> per hour.
> 
> Absent a working understanding of how to use g_source_add_unix_fd(),
> etc., my inclination is to just use g_idle_add_full() and do my own
> non-blocking select() inside my callback. Seems like
> g_source_add_unix_fd() is perhaps better suited to this task, but I
> can't figure out what I need to do vs. what glib can do without me,
> i.e., do I really need to create and attach my own GSource and code
> my own entire set of GSourceFuncs? That would seem to be a hugely
> complicated effort compared to the simple XtAppAddInput() call, or
> even to coding my own select() stuff inside a g_idle_add_full()
> callback. Monitoring a few stray file descriptors within a gtk3
> program would seem to be a not-unusual need, so I am hoping someone
> will tell me that there is an existing GSource somewhere that I can
> just add my own fd into, but that is not at all obvious from the
> documentation.

I do not fully understand your question (especially I don't understand
your reference to using "g_idle_add_full() and do my own non-blocking
select() inside my callback", which would not work), but you can either
use glib's g_poll()/g_source_add_poll() implementation or (on unix) its
g_source_add_unix_fd() implementation to watch on a file descriptor.
The functionality of both is equivalent, and on unix both use poll()
underneath. This may (or may not) help:

https://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/io_watch.cpp

If you want to use glib's g_source_add_poll() implementation rather
than its g_source_add_unix_fd() implementation, you can avoid some of
the boiler plate with g_io_add_watch() - you can use this to call up a
callback function whenever a file descriptor is ready (you don't need
to use the GIOChannel object for any other purpose, such as reading from
or writing to the descriptor):

https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-add-watch

Chris
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

watching a file descriptor in gtk3

[rbd]

Hi all,

I need to monitor a Unix file descriptor for input within my gtk3 program. 
I believe that I need to somehow be using g_source_add_unix_fd() and 
friends but am finding the documentation confusing. Are there any simple 
examples which show how to do this anywhere? (I looked but could not find, 
apologies for any oversight on my part.)


I am porting an old Motif app which used

XtAppAddInput( ... fd ... callbackproc ...)

to register an input handler callbackproc() to be called whenever there 
was input pending on fd. Whatever I use to replace this should NOT block 
for any user-perceivable amount of time when checking fd for pending 
input, which will typically be very small (under 80 bytes) and occurring 
between a few times per second and a few times per hour.


Absent a working understanding of how to use g_source_add_unix_fd(), etc., 
my inclination is to just use g_idle_add_full() and do my own non-blocking 
select() inside my callback. Seems like g_source_add_unix_fd() is perhaps 
better suited to this task, but I can't figure out what I need to do vs. 
what glib can do without me, i.e., do I really need to create and attach 
my own GSource and code my own entire set of GSourceFuncs? That would seem 
to be a hugely complicated effort compared to the simple XtAppAddInput() 
call, or even to coding my own select() stuff inside a g_idle_add_full() 
callback. Monitoring a few stray file descriptors within a gtk3 program 
would seem to be a not-unusual need, so I am hoping someone will tell
me that there is an existing GSource somewhere that I can just add my own 
fd into, but that is not at all obvious from the documentation.


Thanks!

Roger Davis
Univ. of Hawaii

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list