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

[Michael Meeks <michael ximian com>]

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