Re: win32 and glib, socket data inaccessible

[Marc Lehmann <gtk-perl schmorp de>]

On Thu, Jun 30, 2005 at 10:17:15AM -0400, muppet <scott asofyet org> wrote:
> > I am trying to port a gtk2-perl program to windows (in theory an easy
> > task).
> >
> > However, it's using sockets, and the only way to use them in a nonblocking
> > way (under Gtk2) seems to be to use glib watchers. Now, the problem is
> > that, when my callback gets called, glib has already read the data from
> > the filehandle, and there doesn't seem to be support for giochannels in
> > the Glib module, so there is no way to actually get the data.
>
> Have you tried recv() instead of <> or sysread?

No, because, as I wrote, glib already read the socket data, so I assumed
that recv would block just as sysread does (sysread is not really
different to recv).

However, I did try recv, and the result is as expected: it simply blocks
waiting for new data, while the data that triggered the watcher is "lost"
in the glib-internal buffer.

However, it was in some sense "false alarm", as I did some tracing with
G_IO_WIN32_DEBUG=1, and it showed this:

   fileno is 3 at igsueme line 340.
   g_io_channel_win32_new_fd: 3
   g_io_win32_create_watch: fd:3 condition:0x1 handle:0x200

If I read this correctly, it means that g_io_channel_unix_new, which tests
for both socket and normal file, detects that filehandle 3 is not a socket
but a file (it would output a warning if is a socket _and_ a file).

So this probably means that the Glib module passes in the weong filehandle
(the perl fileno, not the windows filehandle).

In 2002 or so I read about this issue, and I think you need a function to
convert between perls idea of fileno and the os idea of a fileno, and glib
should use that function.

I'll do some research.

(Damn, I tried very hard to avoid having to build perl modules for
activestate... it's sooo horrible and maybe I won't even succeed...).

> > interface? (Sorry if it's the latter case).
>
> Not a problem known to me, at least.

Well... :)

> The only hint of the GIOChannel API visible at the perl level is
> Glib::IO::add_watch().  This was by design, because GIOChannel provides
> functionality normally provided by native perl file handles, and we made a
> conscious effort not to duplicate these things.  Personally, i had no idea
> that sockets behaved that way on win32.

win32 has rather weird ways of event multiplexing. basically you have no
multiplexing but instead start a thread for every source (or at least
every type of event source). (in theory there are gazillion cool features
there (overlapped i/o, completion ports, ...), but the most basic use
cases are not solvable without threads and some weird programming).

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg goof com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE