[Vala] bug in IOChannel.read_line and add_watch
Hi all:
I found a bug in IOChannel.read_line: when the line to read ends in \r
and there are no more characters after it, the iochannel can't read more
chars, nor send more IN DATA AVAILABLE events from an add_watch. In
fact, it seems to lock the gtk main loop.
I attach a code that triggers this bug: it creates a pipe, links it to
an IOChannel, and uses a timer to send several strings through it, one
each second. It also monitors the IOChannel with add_watch to print the
data received.
The sentences sent are:
First string\n
Second string\nSecond string b\n
Third string\nThird string b\n\rThird string c\n
Fourth string\nFourth string b\n\r
Fifth string\n
The first, second and third sentences are sent and received fine, even
with the third having a \r in the middle. But the fourth, that ends in
a \r, blocks the IOChannel, and the fifth string is never received,
neither sent (the timer is never triggered after the fourth string).
--
Nos leemos
RASTER(Linux user #228804)
ras...@rastersoft.com http://www.rastersoft.com
using GLib;
using Gtk;
using Posix;
public class test_iochannel: Object {
private IOChannel io_read;
private IOChannel io_write;
private int pipes[2];
private int msg_tosend;
private uint timer;
public bool timer_func() {
var msg=;
size_t v;
switch(msg_tosend) {
case 0:
msg=First string\n;
break;
case 1:
msg=Second string\nSecond string b\n;
break;
case 2:
msg=Third string\nThird string b\n\rThird string c\n;
break;
case 3:
msg=Fourth string\nFourth string b\n\r;
break;
case 4:
msg=Fifth string\n;
break;
default:
break;
}
GLib.stdout.printf(Sending %s\n,msg);
this.io_write.write_chars((char[])msg,out v);
this.io_write.flush();
msg_tosend++;
return (true);
}
public test_iochannel() {
msg_tosend=0;
Posix.pipe(pipes);
this.io_read = new IOChannel.unix_new(pipes[0]);
this.io_write = new IOChannel.unix_new(pipes[1]);
this.io_read.add_watch(IOCondition.HUP|IOCondition.IN,gio_in);
this.timer=GLib.Timeout.add(1000,this.timer_func);
}
private bool gio_in(IOChannel gio, IOCondition condition) {
IOStatus ret;
string msg=;
size_t len;
size_t pos;
if((condition IOCondition.HUP) == IOCondition.HUP) {
return false;
}
GLib.stdout.printf(data\n);
try {
ret = gio.read_line(out msg, out len,out pos);
GLib.stdout.printf(Received: %s (%llu)\n,msg,len);
}
catch(IOChannelError e) {
GLib.stdout.printf(Error channel\n);
}
catch(ConvertError e) {
GLib.stdout.printf(Error conversion\n);
}
return(true);
}
}
int main(string[] args) {
Gtk.init (ref args);
var test=new test_iochannel();
Gtk.main ();
return 0;
}___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] bug in IOChannel.read_line and add_watch
On Sun, 2014-02-02 at 14:10 +0100, rastersoft wrote: Hi all: Hi, I found a bug in IOChannel.read_line: when the line to read ends in \r and there are no more characters after it, the iochannel can't read more chars, nor send more IN DATA AVAILABLE events from an add_watch. In fact, it seems to lock the gtk main loop. I attach a code that triggers this bug: it creates a pipe, links it to an IOChannel, and uses a timer to send several strings through it, one each second. It also monitors the IOChannel with add_watch to print the data received. The sentences sent are: First string\n Second string\nSecond string b\n Third string\nThird string b\n\rThird string c\n Fourth string\nFourth string b\n\r Fifth string\n The first, second and third sentences are sent and received fine, even with the third having a \r in the middle. But the fourth, that ends in a \r, blocks the IOChannel, and the fifth string is never received, neither sent (the timer is never triggered after the fourth string). Thank you very much for finding it out. IOChannel is implemented by glib so probably they'll have more knowledge to find out what's wrong. Also both Vala and GLib are using GNOME Bugzilla[1] to track the bugs so it might be good to post it there (while ML have archives they are not as searchable as Bugzilla and the latter allows to track bugs easier). Best regards PS. You might want to also look on GIO which have nicer interface for Vala and IIRC more features and flexibility. [1] https://bugzilla.gnome.org/ signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] bug in IOChannel.read_line and add_watch
Hi! Yes, after checking the c code generated, I found it, so I filled a bug at bugzilla. Thanks anyway for the tip! El 02/02/14 15:53, Maciej Piechotka escribió: On Sun, 2014-02-02 at 14:10 +0100, rastersoft wrote: Hi all: Hi, I found a bug in IOChannel.read_line: when the line to read ends in \r and there are no more characters after it, the iochannel can't read more chars, nor send more IN DATA AVAILABLE events from an add_watch. In fact, it seems to lock the gtk main loop. I attach a code that triggers this bug: it creates a pipe, links it to an IOChannel, and uses a timer to send several strings through it, one each second. It also monitors the IOChannel with add_watch to print the data received. The sentences sent are: First string\n Second string\nSecond string b\n Third string\nThird string b\n\rThird string c\n Fourth string\nFourth string b\n\r Fifth string\n The first, second and third sentences are sent and received fine, even with the third having a \r in the middle. But the fourth, that ends in a \r, blocks the IOChannel, and the fifth string is never received, neither sent (the timer is never triggered after the fourth string). Thank you very much for finding it out. IOChannel is implemented by glib so probably they'll have more knowledge to find out what's wrong. Also both Vala and GLib are using GNOME Bugzilla[1] to track the bugs so it might be good to post it there (while ML have archives they are not as searchable as Bugzilla and the latter allows to track bugs easier). Best regards PS. You might want to also look on GIO which have nicer interface for Vala and IIRC more features and flexibility. [1] https://bugzilla.gnome.org/ ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
