Re: [g-a-devel]Sync SR Queue with ATSPI

["Draghi Puterity" <mp baum de>]

Hi Michael,

thank you for your competent and detailed answer. I've learned a lot from
it. It is very good news that the glib mainloop can poll devices, and call
me back when they have data, and al this in the same thread as ATSPI. This
approach will certainlly work for Braille devices that are connected through
the serial port. If I encounter similar problems for other type of input
(speech, GConf, etc), I will let you know.

Thanks again,
Draghi


----- Original Message -----
From: "Michael Meeks" <michael ximian com>
To: "Draghi Puterity" <mp baum de>
Cc: "accessibility mailing list" <gnome-accessibility-devel gnome org>;
"BAUM GNOME Development list" <gnome-baum-dev basso SFBay Sun COM>
Sent: Wednesday, January 23, 2002 12:18 PM
Subject: Re: [g-a-devel]Sync SR Queue with ATSPI


> Hi Draghi,
>
> On Wed, 2002-01-23 at 09:07, Draghi Puterity wrote:
> > I think I didn't explain well enough where the actual problem is. I'll
try
> > again.
>
> Great; your new problem statement is much easier for me to understand,
> thanks.
>
> > Let's forget about MT and the async queue for the moment and take the
> > simplest case. The SR has to get input:
> >
> > A) from AT-SPI
> > B) from the Braille device
>
> Right.
>
> > In our current understanding, in order to get input from AT-SPI we have
to
> > call SPI_Event_main. We call it and we stay in it. When should we then
poll
> > and ask the Braille component if it has some input for us and process
it?
>
> Ok - so; since SPI provides no sensible API for this, you need to use
> glib directly. The file to look at is glib/gmain.h. This describes the
> API that is provided for adding polls on file descriptors.
>
> So assuming your input comes from some device that you can open you
> need to do:
>
> static gboolean
> my_input_cb (GIOChannel   *source,
>      GIOCondition  condition,
>      gpointer      data)
> {
> MyClosure *my_closure = data;
>
> g_warning ("Input occured on the fd");
> }
>
> ...
> Before the SPI mainloop starts:
>
> int fd = open ("/dev/foo" ...);
> GIOChannel *channel = g_io_channel_new_unix (fd);
>
> g_io_add_watch (channel, G_IO_IN | G_IO_PRI,
> my_input_cb, my_closure);
>
>
> This will add the file descriptor to the polling glib mainloop. This
> means that until data is available for reading on that file descriptor
> (or an SPI event comes in) we will simply block in the glib mainloop
> 'poll' syscall - which means that all else being equal the CPU will be
> sat in a suspend waiting for hardware stimulation :-)
>
> > I really don't understand what do you mean by "suggest using
non-blocking IO
> > and a poll event driven mainloop". We can poll the Braille with
non-blocking
> > IO calls, but when are we getting a chance to make this calls if we are
> > hanging in the SPI_Event_main?
>
> Ok - so the non-blocking IO comes in with this; you get your poll
> callback, and then you need to read the input on the file descriptor.
> Now - unless you are _certain_ precicely how much data to read from the
> file descriptor you may well block - if you try and read more than is
> available.
>
> To overcome this you really need to use:
>
> fcntl (fd, F_SETFL, O_NONBLOCK);
>
> this means that you'll get a short read, and then on the next read
> errno == EAGAIN, so you need to stash that data until you can read a
> full message - or whatever.
>
> Similarly, with any file you open you really need to use:
>
> fcntl (fd, F_SETFD, FD_CLOEXEC);
>
> since the default unix behavior is somewhat undesirable.
>
> I hope that helps explain what I mean by polling and non-blocking IO ?
>
> Regards,
>
> Michael.
>
> --
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel