Re: [gtkmm] On Glib::IOChannel wrappers

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

Am 13.09.2002 22:21 schrieb(en) Tassos Bassoukos:
> On Fri, 13 Sep 2002, Martin Schulze wrote:
>
> > Am 12.09.2002 23:27 schrieb(en) Tassos Bassoukos:
> [snip]
> > >  * Glib::Source (as currently implemented) cannot wrap non-glibmm
> > > generated GSource's, ergo Glib::IOChannel cannot generte watches,
> >
> > I agree with Murray: A patch adding Glib::Source::Source(GSource*
> source)
> > would be welcome (but probably non-trivial)! :-)
>
> ... with the emphasis on *non*trivial :-) Anyway, I don't yet feel
> comfortable enough with gtkmm internals to tackle such an issue.

:-)

> > > removing
> > > one of IOCHannels more useful features. One could use
> > > SignalIO.connect(int
> > > fd,IOCondition cond), but that is non-portable as Win32 sockets are
> not
> > > represented as ints, and are not regular file descriptors. Also, it
> looks
> > > ugly :-)
> >
> > 1. Just to make clear: You are talking about sockets and not about
> pipes
> > or something similar that is represented by an int ("HANDLE") in Win32
> ?!
> > I do hope that the latter is supported by Glib::IOSource. Since there
> was
> > no feedback so far regarding that matter and I'm not using Win32 I
> don't
> > really know, however! Does GIOChannel support Win32 sockets anyway and
> how?
>
> Yes, gnet supports networking for Unices (therefore also Mac OSX) and
> Win32 with the same API.
>
> > 2. What do you mean by "ugly"? Can you think of a more elegant API?
>
> I meant "ugly" as in "exposes representation to the class user", where
> the
> representation is an int.

Well, since there is no pipe abstraction in glib, it's meant to do this.

> > 3. Talking about portability: In the very first lines of your patch I
> > notice a call to g_io_channel_unix_new(). Are you sure this is a
> > portable function? I remember that I avoided it in the implementation
> > of Glib::IOSource. Also are you sure that g_io_channel_new_file() is
> > portable?
>
> You have a valid point there - the current version is relatively
> win32-unfriendly - for now :). g_io_channel_new_file() is portable, as it
> will just open a local file. (at least the source code was clean)
>
> > 4. I don't want to be ignorant, but why do you need GIOChannel at all?
> > What functionality does it provide that ANSI C++ streaming classes
> don't?
> > Support for Win32 sockets??
>
> Asynchronous notification. Integration with the main event loop. Not
> relying on threads for I/O.
>
> Yes, I too find it strange that i'm the first to experience such a raw
> need ;-) for these wrappers. It is possible that i'm missing something...

You know, if GIOChannel was really platform independant then it would be
very useful, indeed. Since this is not the case, the main advantage
(integration with the main event loop) is equally well implemented
via Glib::IOSource. I don't know about asynchronous notification
but I remember that it is not a good idea for multithreaded programs
so I haven't used it so far. I'm afraid I don't understand the point
"not relying on threads for I/O".

The main reason for adding a Glib::IOChannel wrapper from my point of
view is that it is needed for wrapping other libraries like gnet.

I would prefer then, however, not to depend on g_io_channel_unix_new().
I'd rather skip that functionality.
Also it would be nice if the interface of std::fstream would be met where
possible.
Last, not least, Glib::IOChannel would of cause have to be derivable for
usage in gnetmm. A Glib::Source::Source(GSource*) constructor would have
to be added. I can look into this next week.

Could you please open a bug in bugzilla if you haven't already done this?

Regards,

    Martin