Re: [gtkmm] GLIBMM dispatcher comment

[MHL Schulze t-online de (Martin Schulze)]

Am 16.09.2002 10:08 schrieb(en) Andrew E. Makeev:
> Martin Schulze wrote:
>
> > Am 13.09.2002 15:42 schrieb(en) Andrew E. Makeev:
> > > Murray Cumming wrote:
> > >
> > > > Please add patches to bugzilla.
> > > >
> > > > On Fri, 2002-09-13 at 12:23, Andrew E. Makeev wrote:
> > > > > void fd_set_close_on_exec(int fd)
> > > > > {
> > > > > #ifndef G_OS_WIN32
> > > > >   const int flags = fcntl(fd, F_GETFD, 0);
> > > > >   g_return_if_fail(flags >= 0);
> > > > >
> > > > >   fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
> > > > > #endif
> > > > > }
> > > > >
> > >
> > > no, wait... the dispatcher is not functional on WIN32 for now...
> > > We gonna find the problem first, if it is possible at all...
> >
> > And _is_ there already bug report saying "dispatcher is not
> > functional on WIN32" in bugzilla?
> >
> > Regards,
> >
> >    Martin
>
> Weel, try to guess :).
> As I noticed in previous e-mail Dispatcher was not even linked into
> libglibmm on Win32.

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()?

> Probably, pipes that dispatcher is creating under UNIX
> and under WIN32 is different... I haven't looked at code closely, but my
> friends wonder if you may use GLIB functions to manipulate pipes in
> Dispatcher class. Should GLIB take care about compatibility then for
> you?

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.

Regards,

  Martin