通讯编程

开发平台：
Visual C++

CrtChannel.3：源码内容
							'"
'" Copyright (c) 1996-1997 Sun Microsystems, Inc.
'" Copyright (c) 1997-2000 Ajuba Solutions.
'"
'" See the file "license.terms" for information on usage and redistribution
'" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
'"
'" RCS: @(#) $Id: CrtChannel.3,v 1.16.2.5 2005/10/05 20:35:45 andreas_kupries Exp $
.so man.macros
.TH Tcl_CreateChannel 3 8.4 Tcl "Tcl Library Procedures"
.BS
'" Note:  do not modify the .SH NAME line immediately below!
.SH NAME
Tcl_CreateChannel, Tcl_GetChannelInstanceData, Tcl_GetChannelType, Tcl_GetChannelName, Tcl_GetChannelHandle, Tcl_GetChannelMode, Tcl_GetChannelBufferSize, Tcl_SetChannelBufferSize, Tcl_NotifyChannel, Tcl_BadChannelOption, Tcl_ChannelName, Tcl_ChannelVersion, Tcl_ChannelBlockModeProc, Tcl_ChannelCloseProc, Tcl_ChannelClose2Proc, Tcl_ChannelInputProc, Tcl_ChannelOutputProc, Tcl_ChannelSeekProc, Tcl_ChannelWideSeekProc, Tcl_ChannelSetOptionProc, Tcl_ChannelGetOptionProc, Tcl_ChannelWatchProc, Tcl_ChannelGetHandleProc, Tcl_ChannelFlushProc, Tcl_ChannelHandlerProc, Tcl_ChannelThreadActionProc, Tcl_IsChannelShared, Tcl_IsChannelRegistered, Tcl_CutChannel, Tcl_SpliceChannel, Tcl_IsChannelExisting, Tcl_ClearChannelHandlers, Tcl_GetChannelThread, Tcl_ChannelBuffered - procedures for creating and manipulating channels
.SH SYNOPSIS
.nf
fB#include <tcl.h>fR
.sp
Tcl_Channel
fBTcl_CreateChannelfR(fItypePtr, channelName, instanceData, maskfR)
.sp
ClientData
fBTcl_GetChannelInstanceDatafR(fIchannelfR)
.sp
Tcl_ChannelType *
fBTcl_GetChannelTypefR(fIchannelfR)
.sp
CONST char *
fBTcl_GetChannelNamefR(fIchannelfR)
.sp
int
fBTcl_GetChannelHandlefR(fIchannel, direction, handlePtrfR)
.sp
.VS 8.4
Tcl_ThreadId
fBTcl_GetChannelThreadfR(fIchannelfR)
.VE 8.4
.sp
int
fBTcl_GetChannelModefR(fIchannelfR)
.sp
int
fBTcl_GetChannelBufferSizefR(fIchannelfR)
.sp
fBTcl_SetChannelBufferSizefR(fIchannel, sizefR)
.sp
fBTcl_NotifyChannelfR(fIchannel, maskfR)
.sp
int
fBTcl_BadChannelOptionfR(fIinterp, optionName, optionListfR)
.VS 8.4
.sp
int
fBTcl_IsChannelSharedfR(fIchannelfR)
.sp
int
fBTcl_IsChannelRegisteredfR(fIinterp, channelfR)
.sp
int
fBTcl_IsChannelExistingfR(fIchannelNamefR)
.sp
void
fBTcl_CutChannelfR(fIchannelfR)
.sp
void
fBTcl_SpliceChannelfR(fIchannelfR)
.sp
void
fBTcl_ClearChannelHandlersfR(fIchannelfR)
.VE 8.4
.sp
int
fBTcl_ChannelBufferedfR(fIchannelfR)
.sp
CONST char *
fBTcl_ChannelNamefR(fItypePtrfR)
.sp
Tcl_ChannelTypeVersion
fBTcl_ChannelVersionfR(fItypePtrfR)
.sp
Tcl_DriverBlockModeProc *
fBTcl_ChannelBlockModeProcfR(fItypePtrfR)
.sp
Tcl_DriverCloseProc *
fBTcl_ChannelCloseProcfR(fItypePtrfR)
.sp
Tcl_DriverClose2Proc *
fBTcl_ChannelClose2ProcfR(fItypePtrfR)
.sp
Tcl_DriverInputProc *
fBTcl_ChannelInputProcfR(fItypePtrfR)
.sp
Tcl_DriverOutputProc *
fBTcl_ChannelOutputProcfR(fItypePtrfR)
.sp
Tcl_DriverSeekProc *
fBTcl_ChannelSeekProcfR(fItypePtrfR)
.sp
.VS 8.4
Tcl_DriverWideSeekProc *
fBTcl_ChannelWideSeekProcfR(fItypePtrfR)
.sp
Tcl_DriverThreadActionProc *
fBTcl_ChannelThreadActionProcfR(fItypePtrfR)
.VE 8.4
.sp
Tcl_DriverSetOptionProc *
fBTcl_ChannelSetOptionProcfR(fItypePtrfR)
.sp
Tcl_DriverGetOptionProc *
fBTcl_ChannelGetOptionProcfR(fItypePtrfR)
.sp
Tcl_DriverWatchProc *
fBTcl_ChannelWatchProcfR(fItypePtrfR)
.sp
Tcl_DriverGetHandleProc *
fBTcl_ChannelGetHandleProcfR(fItypePtrfR)
.sp
Tcl_DriverFlushProc *
fBTcl_ChannelFlushProcfR(fItypePtrfR)
.sp
Tcl_DriverHandlerProc *
fBTcl_ChannelHandlerProcfR(fItypePtrfR)
.sp
.SH ARGUMENTS
.AS Tcl_ChannelType *channelName in
.AP Tcl_ChannelType *typePtr in
Points to a structure containing the addresses of procedures that
can be called to perform I/O and other functions on the channel.
.AP "CONST char" *channelName in
The name of this channel, such as fBfile3fR; must not be in use
by any other channel. Can be NULL, in which case the channel is
created without a name.
.AP ClientData instanceData in
Arbitrary one-word value to be associated with this channel.  This
value is passed to procedures in fItypePtrfR when they are invoked.
.AP int mask in
OR-ed combination of fBTCL_READABLEfR and fBTCL_WRITABLEfR to indicate
whether a channel is readable and writable.
.AP Tcl_Channel channel in
The channel to operate on.
.AP int direction in
fBTCL_READABLEfR means the input handle is wanted; fBTCL_WRITABLEfR
means the output handle is wanted.
.AP ClientData *handlePtr out
Points to the location where the desired OS-specific handle should be
stored.
.AP int size in
The size, in bytes, of buffers to allocate in this channel.
.AP int mask in
An OR-ed combination of fBTCL_READABLEfR, fBTCL_WRITABLEfR
and fBTCL_EXCEPTIONfR that indicates events that have occurred on
this channel.
.AP Tcl_Interp *interp in
Current interpreter. (can be NULL)
.AP "CONST char" *optionName in
Name of the invalid option.
.AP "CONST char" *optionList in
Specific options list (space separated words, without "-") 
to append to the standard generic options list.
Can be NULL for generic options error message only.
.BE
.SH DESCRIPTION
.PP
Tcl uses a two-layered channel architecture. It provides a generic upper
layer to enable C and Tcl programs to perform input and output using the
same APIs for a variety of files, devices, sockets etc. The generic C APIs
are described in the manual entry for fBTcl_OpenFileChannelfR.
.PP
The lower layer provides type-specific channel drivers for each type
of device supported on each platform.  This manual entry describes the
C APIs used to communicate between the generic layer and the
type-specific channel drivers.  It also explains how new types of
channels can be added by providing new channel drivers.
.PP
Channel drivers consist of a number of components: First, each channel
driver provides a fBTcl_ChannelTypefR structure containing pointers to
functions implementing the various operations used by the generic layer to
communicate with the channel driver. The fBTcl_ChannelTypefR structure
and the functions referenced by it are described in the section
TCL_CHANNELTYPE, below.
.PP
Second, channel drivers usually provide a Tcl command to create
instances of that type of channel. For example, the Tcl fBopenfR
command creates channels that use the file and command channel
drivers, and the Tcl fBsocketfR command creates channels that use
TCP sockets for network communication.
.PP
Third, a channel driver optionally provides a C function to open
channel instances of that type. For example, fBTcl_OpenFileChannelfR
opens a channel that uses the file channel driver, and
fBTcl_OpenTcpClientfR opens a channel that uses the TCP network
protocol.  These creation functions typically use
fBTcl_CreateChannelfR internally to open the channel.
.PP
To add a new type of channel you must implement a C API or a Tcl command
that opens a channel by invoking fBTcl_CreateChannelfR.
When your driver calls fBTcl_CreateChannelfR it passes in
a fBTcl_ChannelTypefR structure describing the driver's I/O
procedures.
The generic layer will then invoke the functions referenced in that
structure to perform operations on the channel.
.PP
fBTcl_CreateChannelfR opens a new channel and associates the supplied
fItypePtrfR and fIinstanceDatafR with it. The channel is opened in the
mode indicated by fImaskfR.
For a discussion of channel drivers, their operations and the
fBTcl_ChannelTypefR structure, see the section TCL_CHANNELTYPE, below.
.PP
fBTcl_CreateChannelfR interacts with the code managing the standard
channels. Once a standard channel was initialized either through a
call to fBTcl_GetStdChannelfR or a call to fBTcl_SetStdChannelfR
closing this standard channel will cause the next call to
fBTcl_CreateChannelfR to make the new channel the new standard
channel too. See fBTcl_StandardChannelsfR for a general treatise
about standard channels and the behaviour of the Tcl library with
regard to them.
.PP
fBTcl_GetChannelInstanceDatafR returns the instance data associated with
the channel in fIchannelfR. This is the same as the fIinstanceDatafR
argument in the call to fBTcl_CreateChannelfR that created this channel.
.PP
fBTcl_GetChannelTypefR returns a pointer to the fBTcl_ChannelTypefR
structure used by the channel in the fIchannelfR argument. This is
the same as the fItypePtrfR argument in the call to
fBTcl_CreateChannelfR that created this channel.
.PP
fBTcl_GetChannelNamefR returns a string containing the name associated
with the channel, or NULL if the fIchannelNamefR argument to
fBTcl_CreateChannelfR was NULL.
.PP
fBTcl_GetChannelHandlefR places the OS-specific device handle
associated with fIchannelfR for the given fIdirectionfR in the
location specified by fIhandlePtrfR and returns fBTCL_OKfR.  If
the channel does not have a device handle for the specified direction,
then fBTCL_ERRORfR is returned instead.  Different channel drivers
will return different types of handle.  Refer to the manual entries
for each driver to determine what type of handle is returned.
.PP
.VS 8.4
fBTcl_GetChannelThreadfR returns the id of the thread currently managing
the specified fIchannelfR. This allows channel drivers to send their file
events to the correct event queue even for a multi-threaded core.
.VE 8.4
.PP
fBTcl_GetChannelModefR returns an OR-ed combination of fBTCL_READABLEfR
and fBTCL_WRITABLEfR, indicating whether the channel is open for input
and output.
.PP
fBTcl_GetChannelBufferSizefR returns the size, in bytes, of buffers
allocated to store input or output in fIchannelfR. If the value was not set
by a previous call to fBTcl_SetChannelBufferSizefR, described below, then
the default value of 4096 is returned.
.PP
fBTcl_SetChannelBufferSizefR sets the size, in bytes, of buffers that
will be allocated in subsequent operations on the channel to store input or
output. The fIsizefR argument should be between ten and one million,
allowing buffers of ten bytes to one million bytes. If fIsizefR is
outside this range, fBTcl_SetChannelBufferSizefR sets the buffer size to
4096.
.PP
fBTcl_NotifyChannelfR is called by a channel driver to indicate to
the generic layer that the events specified by fImaskfR have
occurred on the channel.  Channel drivers are responsible for invoking
this function whenever the channel handlers need to be called for the
channel.  See fBWATCHPROCfR below for more details.
.PP
fBTcl_BadChannelOptionfR is called from driver specific set or get option
procs to generate a complete error message.
.PP
fBTcl_ChannelBufferedfR returns the number of bytes of input
currently buffered in the internal buffer (push back area) of the
channel itself. It does not report about the data in the overall
buffers for the stack of channels the supplied channel is part of.
.PP
.VS 8.4
fBTcl_IsChannelSharedfR checks the refcount of the specified
fIchannelfR and returns whether the fIchannelfR was shared among
multiple interpreters (result == 1) or not (result == 0).
.PP
fBTcl_IsChannelRegisteredfR checks whether the specified fIchannelfR is
registered in the given fIinterpfRreter (result == 1) or not
(result == 0).
.PP
fBTcl_IsChannelExistingfR checks whether a channel with the specified
name is registered in the (thread)-global list of all channels (result
== 1) or not (result == 0).
.PP
fBTcl_CutChannelfR removes the specified fIchannelfR from the
(thread)global list of all channels (of the current thread).
Application to a channel still registered in some interpreter
is not allowed.
.VS 8.4
Also notifies the driver if the fBTcl_ChannelTypefR version is
fBTCL_CHANNEL_VERSION_4fR (or higher), and
fBTcl_DriverThreadActionProcfR is defined for it.
.VE 8.4
.PP
fBTcl_SpliceChannelfR adds the specified fIchannelfR to the
(thread)global list of all channels (of the current thread).
Application to a channel registered in some interpreter is not allowed.
.VS 8.4
Also notifies the driver if the fBTcl_ChannelTypefR version is
fBTCL_CHANNEL_VERSION_4fR (or higher), and
fBTcl_DriverThreadActionProcfR is defined for it.
.VE 8.4
.PP
fBTcl_ClearChannelHandlersfR removes all channelhandlers and event
scripts associated with the specified fIchannelfR, thus shutting
down all event processing for this channel.
.VE 8.4
.SH TCL_CHANNELTYPE
.PP
A channel driver provides a fBTcl_ChannelTypefR structure that contains
pointers to functions that implement the various operations on a channel;
these operations are invoked as needed by the generic layer.  The structure
was versioned starting in Tcl 8.3.2/8.4 to correct a problem with stacked
channel drivers.  See the fBOLD CHANNEL TYPESfR section below for
details about the old structure.
.PP
The fBTcl_ChannelTypefR structure contains the following fields:
.CS
typedef struct Tcl_ChannelType {
	char *fItypeNamefR;
	Tcl_ChannelTypeVersion fIversionfR;
	Tcl_DriverCloseProc *fIcloseProcfR;
	Tcl_DriverInputProc *fIinputProcfR;
	Tcl_DriverOutputProc *fIoutputProcfR;
	Tcl_DriverSeekProc *fIseekProcfR;
	Tcl_DriverSetOptionProc *fIsetOptionProcfR;
	Tcl_DriverGetOptionProc *fIgetOptionProcfR;
	Tcl_DriverWatchProc *fIwatchProcfR;
	Tcl_DriverGetHandleProc *fIgetHandleProcfR;
	Tcl_DriverClose2Proc *fIclose2ProcfR;
	Tcl_DriverBlockModeProc *fIblockModeProcfR;	
	Tcl_DriverFlushProc *fIflushProcfR;	
	Tcl_DriverHandlerProc *fIhandlerProcfR;	
	Tcl_DriverWideSeekProc *fIwideSeekProcfR;
	Tcl_DriverThreadActionProc *fIthreadActionProcfR;
} Tcl_ChannelType;
.CE
.PP
It is not necessary to provide implementations for all channel
operations.  Those which are not necessary may be set to NULL in the
struct: fIblockModeProcfR, fIseekProcfR, fIsetOptionProcfR,
fIgetOptionProcfR, and fIclose2ProcfR, in addition to
fIflushProcfR, fIhandlerProcfR, and fIthreadActionProcfR.  Other
functions that cannot be implemented in a meaningful way should return
fBEINVALfR when called, to indicate that the operations they
represent are not available. Also note that fIwideSeekProcfR can be
NULL if fIseekProcfR is.
.PP
The user should only use the above structure for fBTcl_ChannelTypefR
instantiation.  When referencing fields in a fBTcl_ChannelTypefR
structure, the following functions should be used to obtain the values:
fBTcl_ChannelNamefR, fBTcl_ChannelVersionfR,
fBTcl_ChannelBlockModeProcfR, fBTcl_ChannelCloseProcfR,
fBTcl_ChannelClose2ProcfR, fBTcl_ChannelInputProcfR,
fBTcl_ChannelOutputProcfR, fBTcl_ChannelSeekProcfR,
.VS 8.4
fBTcl_ChannelWideSeekProcfR,
fBTcl_ChannelThreadActionProcfR,
.VE 8.4
fBTcl_ChannelSetOptionProcfR, fBTcl_ChannelGetOptionProcfR,
fBTcl_ChannelWatchProcfR, fBTcl_ChannelGetHandleProcfR,
fBTcl_ChannelFlushProcfR, or fBTcl_ChannelHandlerProcfR.
.PP
The change to the structures was made in such a way that standard channel
types are binary compatible.  However, channel types that use stacked
channels (ie: TLS, Trf) have new versions to correspond to the above change
since the previous code for stacked channels had problems.
.SH TYPENAME
.PP
The fItypeNamefR field contains a null-terminated string that
identifies the type of the device implemented by this driver, e.g.
fBfilefR or fBsocketfR.
.PP
This value can be retrieved with fBTcl_ChannelNamefR, which returns
a pointer to the string.
.SH VERSION
.PP
The fIversionfR field should be set to the version of the structure
that you require. fBTCL_CHANNEL_VERSION_2fR is the minimum recommended.
.VS 8.4
fBTCL_CHANNEL_VERSION_3fR must be set to specifiy the fIwideSeekProcfR member.
.VE 8.4
.VS 8.4
fBTCL_CHANNEL_VERSION_4fR must be set to specifiy the
fIthreadActionProcfR member (includes fIwideSeekProcfR).
.VE 8.4
If it is not set to any of these, then this
fBTcl_ChannelTypefR is assumed to have the original structure.  See
fBOLD CHANNEL TYPESfR for more details.  While Tcl will recognize
and function with either structures, stacked channels must be of at
least fBTCL_CHANNEL_VERSION_2fR to function correctly.
.PP
This value can be retrieved with fBTcl_ChannelVersionfR, which returns
.VS 8.4
one of fBTCL_CHANNEL_VERSION_4fR, fBTCL_CHANNEL_VERSION_3fR,
.VE 8.4
fBTCL_CHANNEL_VERSION_2fR, or fBTCL_CHANNEL_VERSION_1fR.
.SH BLOCKMODEPROC
.PP
The fIblockModeProcfR field contains the address of a function called by
the generic layer to set blocking and nonblocking mode on the device.
fIBlockModeProcfR should match the following prototype:
.PP
.CS
typedef int Tcl_DriverBlockModeProc(
	ClientData fIinstanceDatafR,
	int fImodefR);
.CE
.PP
The fIinstanceDatafR is the same as the value passed to
fBTcl_CreateChannelfR when this channel was created.  The fImodefR
argument is either fBTCL_MODE_BLOCKINGfR or fBTCL_MODE_NONBLOCKINGfR to
set the device into blocking or nonblocking mode. The function should
return zero if the operation was successful, or a nonzero POSIX error code
if the operation failed.
.PP
If the operation is successful, the function can modify the supplied
fIinstanceDatafR to record that the channel entered blocking or
nonblocking mode and to implement the blocking or nonblocking behavior.
For some device types, the blocking and nonblocking behavior can be
implemented by the underlying operating system; for other device types, the
behavior must be emulated in the channel driver.
.PP
This value can be retrieved with fBTcl_ChannelBlockModeProcfR, which returns
a pointer to the function.
.PP
A channel driver fBnotfR supplying a fIblockModeProcfR has to be
very, very careful. It has to tell the generic layer exactly which
blocking mode is acceptable to it, and should this also document for
the user so that the blocking mode of the channel is not changed to an
inacceptable value. Any confusion here may lead the interpreter into a
(spurious and difficult to find) deadlock.
.SH "CLOSEPROC AND CLOSE2PROC"
.PP
The fIcloseProcfR field contains the address of a function called by the
generic layer to clean up driver-related information when the channel is
closed. fICloseProcfR must match the following prototype:
.PP
.CS
typedef int Tcl_DriverCloseProc(
	ClientData fIinstanceDatafR,
	Tcl_Interp *fIinterpfR);
.CE
.PP
The fIinstanceDatafR argument is the same as the value provided to
fBTcl_CreateChannelfR when the channel was created. The function should
release any storage maintained by the channel driver for this channel, and
close the input and output devices encapsulated by this channel. All queued
output will have been flushed to the device before this function is called,
and no further driver operations will be invoked on this instance after
calling the fIcloseProcfR. If the close operation is successful, the
procedure should return zero; otherwise it should return a nonzero POSIX
error code. In addition, if an error occurs and fIinterpfR is not NULL,
the procedure should store an error message in the interpreter's result.
.PP
Alternatively, channels that support closing the read and write sides
independently may set fIcloseProcfR to fBTCL_CLOSE2PROCfR and set
fIclose2ProcfR to the address of a function that matches the
following prototype:
.PP
.CS
typedef int Tcl_DriverClose2Proc(
	ClientData fIinstanceDatafR,
	Tcl_Interp *fIinterpfR,
	int fIflagsfR);
.CE
.PP
The fIclose2ProcfR will be called with fIflagsfR set to an OR'ed
combination of fBTCL_CLOSE_READfR or fBTCL_CLOSE_WRITEfR to
indicate that the driver should close the read and/or write side of
the channel.  The channel driver may be invoked to perform
additional operations on the channel after fIclose2ProcfR is
called to close one or both sides of the channel.  If fIflagsfR is
fB0fR (zero), the driver should close the channel in the manner
described above for fIcloseProcfR.  No further operations will be
invoked on this instance after fIclose2ProcfR is called with all
flags cleared.  In all cases, the fIclose2ProcfR function should
return zero if the close operation was successful; otherwise it should
return a nonzero POSIX error code. In addition, if an error occurs and
fIinterpfR is not NULL, the procedure should store an error message
in the interpreter's result.
.PP
These value can be retrieved with fBTcl_ChannelCloseProcfR or
fBTcl_ChannelClose2ProcfR, which returns a pointer to the respective
function.
.SH INPUTPROC
.PP
The fIinputProcfR field contains the address of a function called by the
generic layer to read data from the file or device and store it in an
internal buffer. fIInputProcfR must match the following prototype:
.PP
.CS
typedef int Tcl_DriverInputProc(
	ClientData fIinstanceDatafR,
	char *fIbuffR,
	int fIbufSizefR,
	int *fIerrorCodePtrfR);
.CE
.PP
fIInstanceDatafR is the same as the value passed to
fBTcl_CreateChannelfR when the channel was created.  The fIbuffR
argument points to an array of bytes in which to store input from the
device, and the fIbufSizefR argument indicates how many bytes are
available at fIbuffR.
.PP
The fIerrorCodePtrfR argument points to an integer variable provided by
the generic layer. If an error occurs, the function should set the variable
to a POSIX error code that identifies the error that occurred.
.PP
The function should read data from the input device encapsulated by the
channel and store it at fIbuffR.  On success, the function should return
a nonnegative integer indicating how many bytes were read from the input
device and stored at fIbuffR. On error, the function should return -1. If
an error occurs after some data has been read from the device, that data is
lost.
.PP
If fIinputProcfR can determine that the input device has some data
available but less than requested by the fIbufSizefR argument, the
function should only attempt to read as much data as is available and
return without blocking. If the input device has no data available
whatsoever and the channel is in nonblocking mode, the function should
return an fBEAGAINfR error. If the input device has no data available
whatsoever and the channel is in blocking mode, the function should block
for the shortest possible time until at least one byte of data can be read
from the device; then, it should return as much data as it can read without
blocking.
.PP
This value can be retrieved with fBTcl_ChannelInputProcfR, which returns
a pointer to the function.
.SH OUTPUTPROC
.PP
The fIoutputProcfR field contains the address of a function called by the
generic layer to transfer data from an internal buffer to the output device.
fIOutputProcfR must match the following prototype:
.PP
.CS
typedef int Tcl_DriverOutputProc(
	ClientData fIinstanceDatafR,
	CONST char *fIbuffR,
	int fItoWritefR,
	int *fIerrorCodePtrfR);
.CE
.PP
fIInstanceDatafR is the same as the value passed to
fBTcl_CreateChannelfR when the channel was created. The fIbuffR
argument contains an array of bytes to be written to the device, and the
fItoWritefR argument indicates how many bytes are to be written from the
fIbuffR argument.
.PP
The fIerrorCodePtrfR argument points to an integer variable provided by
the generic layer. If an error occurs, the function should set this
variable to a POSIX error code that identifies the error.
.PP
The function should write the data at fIbuffR to the output device
encapsulated by the channel. On success, the function should return a
nonnegative integer indicating how many bytes were written to the output
device.  The return value is normally the same as fItoWritefR, but may be
less in some cases such as if the output operation is interrupted by a
signal. If an error occurs the function should return -1.  In case of
error, some data may have been written to the device.
.PP
If the channel is nonblocking and the output device is unable to absorb any
data whatsoever, the function should return -1 with an fBEAGAINfR error
without writing any data.
.PP
This value can be retrieved with fBTcl_ChannelOutputProcfR, which returns
a pointer to the function.
.SH "SEEKPROC AND WIDESEEKPROC"
.PP
The fIseekProcfR field contains the address of a function called by the
generic layer to move the access point at which subsequent input or output
operations will be applied. fISeekProcfR must match the following
prototype:
.PP
.CS
typedef int Tcl_DriverSeekProc(
	ClientData fIinstanceDatafR,
	long fIoffsetfR,
	int fIseekModefR,
	int *fIerrorCodePtrfR);
.CE
.PP
The fIinstanceDatafR argument is the same as the value given to
fBTcl_CreateChannelfR when this channel was created.  fIOffsetfR and
fIseekModefR have the same meaning as for the fBTcl_SeekfR
procedure (described in the manual entry for fBTcl_OpenFileChannelfR).
.PP
The fIerrorCodePtrfR argument points to an integer variable provided by
the generic layer for returning fBerrnofR values from the function.  The
function should set this variable to a POSIX error code if an error occurs.
The function should store an fBEINVALfR error code if the channel type
does not implement seeking.
.PP
The return value is the new access point or -1 in case of error. If an
error occurred, the function should not move the access point.
.PP
.VS 8.4
If there is a non-NULL fIseekProcfR field, the fIwideSeekProcfR
field may contain the address of an alternative function to use which
handles wide (i.e. larger than 32-bit) offsets, so allowing seeks
within files larger than 2GB.  The fIwideSeekProcfR will be called
in preference to the fIseekProcfR, but both must be defined if the
fIwideSeekProcfR is defined.  fIWideSeekProcfR must match the
following prototype:
.PP
.CS
typedef Tcl_WideInt Tcl_DriverWideSeekProc(
	ClientData fIinstanceDatafR,
	Tcl_WideInt fIoffsetfR,
	int fIseekModefR,
	int *fIerrorCodePtrfR);
.CE
.PP
The arguments and return values mean the same thing as with
fIseekProcfR above, except that the type of offsets and the return
type are different.
.PP
The fIseekProcfR value can be retrieved with
fBTcl_ChannelSeekProcfR, which returns a pointer to the function,
and similarly the fIwideSeekProcfR can be retrieved with
fBTcl_ChannelWideSeekProcfR.
.VE 8.4
.SH SETOPTIONPROC
.PP
The fIsetOptionProcfR field contains the address of a function called by
the generic layer to set a channel type specific option on a channel.
fIsetOptionProcfR must match the following prototype:
.PP
.CS
typedef int Tcl_DriverSetOptionProc(
	ClientData fIinstanceDatafR,
	Tcl_Interp *fIinterpfR,
	CONST char *fIoptionNamefR,
	CONST char *fInewValuefR);
.CE
.PP
fIoptionNamefR is the name of an option to set, and fInewValuefR is
the new value for that option, as a string. The fIinstanceDatafR is the
same as the value given to fBTcl_CreateChannelfR when this channel was
created. The function should do whatever channel type specific action is
required to implement the new value of the option.
.PP
Some options are handled by the generic code and this function is never
called to set them, e.g. fB-blockmodefR. Other options are specific to
each channel type and the fIsetOptionProcfR procedure of the channel
driver will get called to implement them. The fIsetOptionProcfR field can
be NULL, which indicates that this channel type supports no type specific
options. 
.PP
If the option value is successfully modified to the new value, the function
returns fBTCL_OKfR.
It should call fBTcl_BadChannelOptionfR which itself returns
fBTCL_ERRORfR if the fIoptionNamefR is
unrecognized. 
If fInewValuefR specifies a value for the option that
is not supported or if a system call error occurs,
the function should leave an error message in the
fIresultfR field of fIinterpfR if fIinterpfR is not NULL. The
function should also call fBTcl_SetErrnofR to store an appropriate POSIX
error code.
.PP
This value can be retrieved with fBTcl_ChannelSetOptionProcfR, which returns
a pointer to the function.
.SH GETOPTIONPROC
.PP
The fIgetOptionProcfR field contains the address of a function called by
the generic layer to get the value of a channel type specific option on a
channel. fIgetOptionProcfR must match the following prototype:
.PP
.CS
typedef int Tcl_DriverGetOptionProc(
	ClientData fIinstanceDatafR,
	Tcl_Interp *fIinterpfR,
	CONST char *fIoptionNamefR,
	Tcl_DString *fIoptionValuefR);
.CE
.PP
fIOptionNamefR is the name of an option supported by this type of
channel. If the option name is not NULL, the function stores its current
value, as a string, in the Tcl dynamic string fIoptionValuefR.
If fIoptionNamefR is NULL, the function stores in fIoptionValuefR an
alternating list of all supported options and their current values.
On success, the function returns fBTCL_OKfR. 
It should call fBTcl_BadChannelOptionfR which itself returns
fBTCL_ERRORfR if the fIoptionNamefR is
unrecognized. If a system call error occurs,
the function should leave an error message in the
result of fIinterpfR if fIinterpfR is not NULL. The
function should also call fBTcl_SetErrnofR to store an appropriate POSIX
error code.
.PP
Some options are handled by the generic code and this function is never
called to retrieve their value, e.g. fB-blockmodefR. Other options are
specific to each channel type and the fIgetOptionProcfR procedure of the
channel driver will get called to implement them. The fIgetOptionProcfR
field can be NULL, which indicates that this channel type supports no type
specific options.
.PP
This value can be retrieved with fBTcl_ChannelGetOptionProcfR, which returns
a pointer to the function.
.SH WATCHPROC
.PP
The fIwatchProcfR field contains the address of a function called
by the generic layer to initialize the event notification mechanism to
notice events of interest on this channel.
fIWatchProcfR should match the following prototype:
.PP
.CS
typedef void Tcl_DriverWatchProc(
	ClientData fIinstanceDatafR,
	int fImaskfR);
.CE
.PP
The fIinstanceDatafR is the same as the value passed to
fBTcl_CreateChannelfR when this channel was created. The fImaskfR
argument is an OR-ed combination of fBTCL_READABLEfR, fBTCL_WRITABLEfR
and fBTCL_EXCEPTIONfR; it indicates events the caller is interested in
noticing on this channel.
.PP
The function should initialize device type specific mechanisms to
notice when an event of interest is present on the channel.  When one
or more of the designated events occurs on the channel, the channel
driver is responsible for calling fBTcl_NotifyChannelfR to inform
the generic channel module.  The driver should take care not to starve
other channel drivers or sources of callbacks by invoking
Tcl_NotifyChannel too frequently.  Fairness can be insured by using
the Tcl event queue to allow the channel event to be scheduled in sequence
with other events.  See the description of fBTcl_QueueEventfR for
details on how to queue an event.
.PP
This value can be retrieved with fBTcl_ChannelWatchProcfR, which returns
a pointer to the function.
.SH GETHANDLEPROC
.PP
The fIgetHandleProcfR field contains the address of a function called by
the generic layer to retrieve a device-specific handle from the channel.
fIGetHandleProcfR should match the following prototype:
.PP
.CS
typedef int Tcl_DriverGetHandleProc(
	ClientData fIinstanceDatafR,
	int fIdirectionfR,
	ClientData *fIhandlePtrfR);
.CE
.PP
fIInstanceDatafR is the same as the value passed to
fBTcl_CreateChannelfR when this channel was created. The fIdirectionfR
argument is either fBTCL_READABLEfR to retrieve the handle used
for input, or fBTCL_WRITABLEfR to retrieve the handle used for
output.
.PP
If the channel implementation has device-specific handles, the
function should retrieve the appropriate handle associated with the
channel, according the fIdirectionfR argument.  The handle should be
stored in the location referred to by fIhandlePtrfR, and
fBTCL_OKfR should be returned.  If the channel is not open for the
specified direction, or if the channel implementation does not use
device handles, the function should return fBTCL_ERRORfR.
.PP
This value can be retrieved with fBTcl_ChannelGetHandleProcfR, which returns
a pointer to the function.
.SH FLUSHPROC
.PP
The fIflushProcfR field is currently reserved for future use.
It should be set to NULL.
fIFlushProcfR should match the following prototype:
.PP
.CS
typedef int Tcl_DriverFlushProc(
	ClientData fIinstanceDatafR);
.CE
.PP
This value can be retrieved with fBTcl_ChannelFlushProcfR, which returns
a pointer to the function.
.SH HANDLERPROC
.PP
The fIhandlerProcfR field contains the address of a function called by
the generic layer to notify the channel that an event occurred.  It should
be defined for stacked channel drivers that wish to be notified of events
that occur on the underlying (stacked) channel.
fIHandlerProcfR should match the following prototype:
.PP
.CS
typedef int Tcl_DriverHandlerProc(
	ClientData fIinstanceDatafR,
	int fIinterestMaskfR);
.CE
.PP
fIInstanceDatafR is the same as the value passed to fBTcl_CreateChannelfR
when this channel was created.  The fIinterestMaskfR is an OR-ed
combination of fBTCL_READABLEfR or fBTCL_WRITABLEfR; it indicates what
type of event occurred on this channel.
.PP
This value can be retrieved with fBTcl_ChannelHandlerProcfR, which returns
a pointer to the function.
.VS 8.4
.SH "THREADACTIONPROC"
.PP
The fIthreadActionProcfR field contains the address of the function
called by the generic layer when a channel is created, closed, or
going to move to a different thread, i.e. whenever thread-specific
driver state might have to initialized or updated. It can be NULL.
The action fITCL_CHANNEL_THREAD_REMOVEfR is used to notify the
driver that it should update or remove any thread-specific data it
might be maintaining for the channel.
.PP
The action fITCL_CHANNEL_THREAD_INSERTfR is used to notify the
driver that it should update or initialize any thread-specific data it
might be maintaining using the calling thread as the associate. See
fBTcl_CutChannelfR and fBTcl_SpliceChannelfR for more detail.
.PP
.CS
typedef void Tcl_DriverThreadActionProc(
	ClientData fIinstanceDatafR,
      int        fIactionfR);
.CE
.PP
fIInstanceDatafR is the same as the value passed to
fBTcl_CreateChannelfR when this channel was created.
.PP
These values can be retrieved with fBTcl_ChannelThreadActionProcfR,
which returns a pointer to the function.
.VE 8.4
.SH TCL_BADCHANNELOPTION
.PP
This procedure generates a "bad option" error message in an
(optional) interpreter.  It is used by channel drivers when 
a invalid Set/Get option is requested. Its purpose is to concatenate
the generic options list to the specific ones and factorize
the generic options error message string.
.PP
It always return fBTCL_ERRORfR
.PP
An error message is generated in fIinterpfR's result object to
indicate that a command was invoked with the a bad option
The message has the form
.CS
    bad option "blah": should be one of 
    <...generic options...>+<...specific options...>
so you get for instance:
    bad option "-blah": should be one of -blocking,
    -buffering, -buffersize, -eofchar, -translation,
    -peername, or -sockname
when called with fIoptionListfR="peername sockname"
.CE
``blah'' is the fIoptionNamefR argument and ``<specific options>''
is a space separated list of specific option words.
The function takes good care of inserting minus signs before
each option, commas after, and an ``or'' before the last option.
.SH "OLD CHANNEL TYPES"
The original (8.3.1 and below) fBTcl_ChannelTypefR structure contains
the following fields:
.PP
.CS
typedef struct Tcl_ChannelType {
	char *fItypeNamefR;
	Tcl_DriverBlockModeProc *fIblockModeProcfR;	
	Tcl_DriverCloseProc *fIcloseProcfR;
	Tcl_DriverInputProc *fIinputProcfR;
	Tcl_DriverOutputProc *fIoutputProcfR;
	Tcl_DriverSeekProc *fIseekProcfR;
	Tcl_DriverSetOptionProc *fIsetOptionProcfR;
	Tcl_DriverGetOptionProc *fIgetOptionProcfR;
	Tcl_DriverWatchProc *fIwatchProcfR;
	Tcl_DriverGetHandleProc *fIgetHandleProcfR;
	Tcl_DriverClose2Proc *fIclose2ProcfR;
} Tcl_ChannelType;
.CE
.PP
It is still possible to create channel with the above structure.  The
internal channel code will determine the version.  It is imperative to use
the new fBTcl_ChannelTypefR structure if you are creating a stacked
channel driver, due to problems with the earlier stacked channel
implementation (in 8.2.0 to 8.3.1).
.PP
.VS 8.4
Prior to 8.4.0 (i.e. during the later releases of 8.3 and early part
of the 8.4 development cycle) the fBTcl_ChannelTypefR structure
contained the following fields:
.PP
.CS
typedef struct Tcl_ChannelType {
	char *fItypeNamefR;
	Tcl_ChannelTypeVersion fIversionfR;
	Tcl_DriverCloseProc *fIcloseProcfR;
	Tcl_DriverInputProc *fIinputProcfR;
	Tcl_DriverOutputProc *fIoutputProcfR;
	Tcl_DriverSeekProc *fIseekProcfR;
	Tcl_DriverSetOptionProc *fIsetOptionProcfR;
	Tcl_DriverGetOptionProc *fIgetOptionProcfR;
	Tcl_DriverWatchProc *fIwatchProcfR;
	Tcl_DriverGetHandleProc *fIgetHandleProcfR;
	Tcl_DriverClose2Proc *fIclose2ProcfR;
	Tcl_DriverBlockModeProc *fIblockModeProcfR;	
	Tcl_DriverFlushProc *fIflushProcfR;	
	Tcl_DriverHandlerProc *fIhandlerProcfR;	
} Tcl_ChannelType;
.CE
.PP
When the above structure is registered as a channel type, the
fIversionfR field should always be fBTCL_CHANNEL_VERSION_2fR.
.VE 8.4
.SH "SEE ALSO"
Tcl_Close(3), Tcl_OpenFileChannel(3), Tcl_SetErrno(3), Tcl_QueueEvent(3), Tcl_StackChannel(3), Tcl_GetStdChannel(3)
.SH KEYWORDS
blocking, channel driver, channel registration, channel type, nonblocking

						