Re: async file i/o

[Michael Rothwell <rothwell holly-springs nc us>]

Havoc Pennington wrote:
> Michael Rothwell <rothwell holly-springs nc us> writes:
> > David Helder wrote:
> >
> > > O_NONBLOCK should work.  E.g.:
> > >   state->fd = open (state->pathname, O_RDONLY | O_NONBLOCK);
> > >
> > > Then you can use select() or create an IOChannel from the file handle and
> > > use g_io_channel_add_watch().
> >
> > I just wrote a small program using glade to read a file from a floppy in
> > 4096 byte chunks, using O_NONBLOCK and GIOChannel. It blocks. :(
>
> If you use the main loop (g_io_channel_add_watch(), g_main_run() or
> gtk_main()), then O_NONBLOCK isn't needed, because read() won't block
> as long as at least one byte is available for reading; your GIOFunc
> callback will only be invoked by the main loop if there's at least one
> byte.

I tried using read() and the GIOChannel read function. Perhaps if I only
ever read() one byte? That would make it pretty slow, though...

> I think fread() on the other hand will always block, though I could be
> wrong.
>
> Of course the main-loop-async may not be what you want, if you want
> threads then GIOChannel isn't going to get you anywhere.

I don't actually want threads. I want async I/O.
 
> Still, O_NONBLOCK should work I think, are you sure you are blocking
> on the file descriptor? (see strace output) - maybe you are just
> busy-looping by not checking for EAGAIN?

Blocking on read(). I check for EAGAIN, and if I busy-loop, the
interface should still be responsive. It's not.



I'm debugging my thread-per-open() async disk i/o library. It's got a
strange race condition at the moment. Such is threads. What would, in
your opinion, be the optimum method for a thread to notify the main gtk
program that it should do something? I'm currently doing this:

 
gdk_threads_enter();
gtk_idle_add_priority();
gdk_threads_leave();
 
... which causes the main thread to run my polling function, which
checks the struct that holds the shared data to see if a request has
been completed. This should always be true, and the callback removes
itself from the idle loop. That's a lot of in-and-out of the idle loop.
Would it be better to use signals?


-M