How to access a channel from C when it is created in script?
TclEnthusiast
I am new to the C/C++ API of Tcl. Is there any way for a C extension
to use a pipe created in Tcl script?
set pipe [open "| tclsh" r+]
file5
The string "file5" seems to be a name of the channel. How can a C/C++
extension code know about "file5". I appreciate your help.
Regards
Sandip
Alexandre Ferrieux
wrote:
Read the .3 manpages, they explain the C API in detail.
On the CrtChannel.3 manpage you'll find that Tcl_GetChannelHandle is
your friend.
However, before going further into your extension, I'd suggest
exhausting the options given by separate processes. Indeed, a command
pipeline is itself typical of interprocess communication; except for
carefully justified situations where performance is at stake (give
figures), doing the extra work in an extra child is nearly always
simpler and easier to maintain.
-Alex
bobicanprogram
wrote:
Depending on what you are actually trying to do with your C++
extension you might find the Tcl/Tk-C++ hooks in the SIMPL project
helpful.
http://www.icanprogram.com/simpl
http://www.icanprogram.com/simpl/tclbin.self.html
There are some examples of Tcl->C here:
http://www.icanprogram.com/hosug
bob
tom.rmadilo
wrote:
> However, before going further into your extension, I'd suggest
> exhausting the options given by separate processes. Indeed, a command
> pipeline is itself typical of interprocess communication; except for
> carefully justified situations where performance is at stake (give
> figures), doing the extra work in an extra child is nearly always
> simpler and easier to maintain.
Best advice I've read in a long time. A command pipeline is "IPC for
Free".
Well, not exactly free. You have to give up bi-directional
communication. In other words, you have a filter. Input to process A
is transformed into input to process B, etc. The only real
communication is boiled down to the ability of the child to receive
and the existence of data to be received from the parent.
What would be nice is a double pipe, or a communication loop. By
default the return path would be a straight pass-back to the original
process, through the intermediate processes, for instance if a process
does not read/write on the return path (the current case for all
code), the OS will simply bypass that process (so no need to change
existing code).
Assuming the endpoint processes are a typical client or server, none
of the individual programs would need any change (assuming they read
stdio and write stdout).
Alexandre Ferrieux
For $::env(upper_floor)'s sake Tom, do you really think going on a
random tangent like that helps ? I'm trying to eliminate the
possibility of the OP working too hard (by wrestling with Tcl
internals while he could have been content with I/O), and you come up
with 3rd-order hairsplitting on IPC philosophy... Why don't you write
tha very same tangent in a thread by itself ?
-Alex
tom.rmadilo
wrote:
Yes, sorry. Sometimes I need a sock stuffed down my throat. I'll end
this post before starting another tangent.