[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    [gimp-devel] Pipe encapsulation in GDK and the GIMP
From:       Tor Lillqvist <tml () hemuli ! tte ! vtt ! fi>
Date:       1998-09-25 8:50:33
[Download RAW message or body]

Hello,

Yesterday I started to implement plug-ins in the Windows port. The
first problem was that named pipes aren't avaibale on Windows 95.

Named pipes would apparently have provided just the right
functionality needed. So, I decided to try anonymous pipes then. The
problem is that you cannot do anything like select() on anonymous
pipes. (Unless, I have misunderstood the documentation.) So, I thought
I'll post a Windows message to the reader thread (process) when there
is something to be read in the pipe.

This means that simply passing an "int fd" to gdk_add_input, and all
the functions in gimpwire, gimpprotocol et al isn't enough. On
Windows, I need a structure with the pipe handle and the thread id of
the reader thread to be able to post the message.

I resolved this by using an encapsulating struct, GIOChannel, that
contains just the file descriptor on Unix (and on Windows if using the
GNU-Win32 emulation layer), and the necessary cruft on native Windows.
I changed the relevant functions to pass around (a pointer to) a
GIOChannel object instead.

In my humble opinion, this makes the add_input stuff and plug-in
communication mechanism a bit cleaner in general, as there is no need
to make the IPC mechanism used so visible except for in the routines
that actually read and write stuff. Presumably, if for some reason one
would want to some day use another IPC mechanism than pipes on Unix,
the GIOChannel struct would hide this cleanly as well.

Is there any chance that this change will be accepted? If not, I could
always keep stuff as is, using "int fd", but in reality, in the
Windows port, the file dscriptor would be a pointer struct as
mentioned above...

(I'm open to suggestions of a better name than GIOChannel. Also, I put
it into GLib, would some other library have been a better place? GDK
maybe, as the GDK event wait function has to use it?)

--tml

P.S. If people have trouble accessing my web site, there has been
severe IP routing problems for almost a day now here, sigh.

[prev in list] [next in list] [prev in thread] [next in thread]