Re: [gtkmm] Glib::SignalIO

[Tassos Bassoukos <abas aix meng auth gr>]

Peter Gasper wrote:
> My application is reading information from the serial port. I first wrote a test 
> program that ran from the command-line to do this. Then I set about incorporating it 
> into my gtkmm app. It originally used the sigaction SIGIO signal to implement
> asynchronous IO, which worked really well. However when I brought it into my app I had
> problems with the line:
> 	sa.sa_handler = on_input_received;
> Which previously was just a regular function, but now in my app is part of a class,
> which causes the compiler warning: 
> 	"cannot convert 'void (Serial::*)(int)' to 'void (*)(int)' in assignment"
> for the line:
> 	sa.sa_handler = &Serial::on_input_received;

Hello Peter,
The problem is that the on_input_received method is an instance method, 
which requires an instance to be invoked. You will need to make the 
method static. If you have several instances of the class, simply create 
a static member method that determines the appropriate instance for that 
method.

> Now maybe there is a code solution to this, but I don't know it. So I changed to using
> Glib::SignalIO function, which one would expect to have the same functionality.
> Therein lies the problem.
>
> 1. I had been using pause(), which pauses my function until the sigaction SIGIO signal
> 	is received, I cannot find a similar functionality for Glib::SignalIO.
> 2. Unlike the sigaction SIGIO (which calls only while input is available),
> 	the Glib::SignalIO repeatedly calls my slot until I return false, even if
> 	no more data is available. 

Umm... you have selected *reading* only for that SignalIO, correct?

> Because of this I return false so I don't get
> 	false signals. But this means I must reconnect the slot to the SignalIO
> 	which means I could potentially miss a signal for incoming data. Which means
> 	Glib::SignalIO acts more like an unreliable signal than a reliable signal 
> 	such as sigaction SIGIO.
>
> > From the documentation it also appears that all Glib::SignalIO does is poll fd, which
> I can do myself, but I was trying to avoid polling (which is more CPU intensive). 

IIRC (and I think I do), Glib::SignalIO adds the specified fd to the 
select syscall at the heart of the event loop. On some systems, this 
might be implemented as poll(), but this will not affect your programm[0]

> Any ideas?

You could allways use a separate thread for the reading.... Just an idea.

Tassos
[0] Unless of course you have a need of real-time communication with the 
serial port, without any buffering, in which case the case needs 
reconsidering.