Re: [gtkmm] GLIBMM dispatcher comment

["Andrew E. Makeev" <andrew solvo ru>]

Martin Schulze wrote:

>
> But there are no comment in the source that would justify this behaviour.
> So there is no reason _not_ to open a bugzilla bug. Please do it and add
> backtrace or any information that could help to solve the problem.
>
> > Problem was found in MsgWaitForMultipleObjects() call when we "switched"
> > dispatcher on.
>
> I'm afraid this information is not very helpful. Does your program segfault
> while in MsgWaitForMultipleObjects()?
>

I suggest, you just go into gtkmm/glib/glibmm directory and add dispatcher.lo
in object list for building libglibmm-1.3.la.
Probably, you will have to comment body of function

    void fd_set_close_on_exec(int fd).

ReBuild libs, then just go to gtkmm/examples/thread and try dispatcher.cc.

Shortly, MsgWaitForMultipleObjects is expecting different HANDLE type in it's
parameters than it has from pipe opened by Dispatcher. See also comment from
gmain.h:

 * On Win32, the fd in a GPollFD should be Win32 HANDLE (*not* a file
 * descriptor as provided by the C runtime) that can be used by
 * MsgWaitForMultipleObjects. This does *not* include file handles
 * from CreateFile, SOCKETs, nor pipe handles. (But you can use
 * WSAEventSelect to signal events when a SOCKET is readable).

So, what should I start on bugzilla? Something like "Please, improve
Dispatcher to let it support Win32"?

> I don't know the differences between pipes under UNIX and WIN32. I have
> the idealistic view that both are files I can read and write from/into.
> And add the file descriptor (or HANDLE) to some poll list. As for the
> differences between polling under UNIX and WIN32 I do expect glib to care
> about compatibility.

Well, I guess, it was my mistake to compare pipes... As you've seen above the
problem is to have Win32 HANDLE instead of pipe handle (file descriptor).

Regards,
-andrew