Re: win32 and glib, socket data inaccessible

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

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
      --==---/ / _ \/ // /\ \/ /
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]