At Wed, 8 Jul 2009 07:34:47 -0700 (PDT) Roger O <roger.oberholtzer@gmail.com> wrote:

>
> On Jul 8, 3:06=A0pm, David Gravereaux <davyg...@pobox.com> wrote:
>
> > Ok, write a Tcl extension that contains Tcl_GetChannelHandle and
> > executes your C code (which I'll assume is an executable).
>
> The code is part of an image processing library that runs in numerous
> places. This is only one. Sometimes the code runs on numerous
> computers in a cluster, and these file descriptors refer to sockets.

To what extent is the *I/O* interspersed with the *image processing*?
From my own experience with image processing (I worked at the UMass
Image Understanding Laboratory for over 20 years), it was often the case
that an image processing program would look like this psuedo code:

get parameters;
read images from disk in to memory;
process images loaded in memory;
write output images (or other data) out to disk;
display statisics or other information;

If your image processing library can be separated into two
sub-libraries, an image I/O library (reads and writes image data between
some external source and memory) and an image processing library (which
only processes in-memory images), then it makes sense to have two
versions of the image I/O library (possibly built from a single code
source using #ifdefs -- which you will need anyway), one version using
'native' I/O (eg open/read/write/close under UNIX and whatever
MS-Windows uses instead of open/read/write/close) and one version using
Tcl's I/O functions
(Tcl_OpenChannel/Tcl_Read/Tcl_Write/Tcl_CloseChannel). Both library act
on some commonly defined in-memory image structure object which gets
passed to/from the image processing library.

> Sometimes the code runs as part of a Tcl/Tk GUI all on a local
> machine, and these very same file descriptors refer to local files. In
> both cases, the C code is dynamically loaded. There is Tcl/Tk GUI in
> both uses. This works because in the Unix/Linux Tcl, both the open and
> the socket command return the file descriptor as part of the return
> value. As long as the GUI always ran on Linux, I was a happy camper.
>
> On Windows, I do not care if it is a HANDLE reference that is
> returned. I can access that as well.
>
> > On Windows, you'll get a HANDLE rather than a FILE*, though, so use of
> > fgets()/fwrite() isn't valid for good xplat'ability. =A0I do like Kieran'=
> s
> > advice for use of _open_osfhandle().
>
> If Windows returns a HANDLE, and Unix/Linux an integer file descriptor
> (which it does and which works with read/write), than I would imagine
> on no platforms does Tcl return a FILE *. I don't mind which is
> returned. As long as I know what it is. I can handle the x-platform in
> my image processing library. Even if Tcl offers an alternative. The
> problem is that the alternative may be too obtrusive. So, I am
> checking my options.
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/