Inheritance diagram for IConduit:
Public Types | |
enum | { Eof = -1 } |
Public Member Functions | |
void | attach (IConduitSource input) |
void | attach (IConduitSink output) |
int | read (IBuffer target) |
int | write (IBuffer source) |
IConduit | copy (IConduit source) |
IConduit | flush (IBuffer source) |
IBuffer | createBuffer () |
bool | isReadable () |
bool | isWritable () |
bool | isSeekable () |
protected void | closure () |
Object | getLock () |
void | setLock (Object lock) |
void | acquire () |
bool | acquireIfOpen () |
void | close () |
Private Member Functions | |
int | reader (void[] dst) |
void | bind (IConduitSource next) |
void | unbind () |
int | writer (void[] src) |
void | bind (IConduitSink next) |
void | unbind () |
Additional kinds of conduit are easy to construct: one either subclasses mango.io.Conduit, or implements mango.io.model.IConduit. A conduit reads and writes from/to an IBuffer in large chunks, typically the entire buffer.
Definition at line 56 of file IConduit.d.
|
Declare the End Of File identifer Definition at line 64 of file IConduit.d. |
|
Attach a filter to the IConduit input. The filter is invoked via its reader(void[]) method whenever a block of content is being read; the void[] array represents content destination. The filter should return the number of bytes it has actually produced: less than or equal to the length of the provided array. Filters are chained together such that the last filter added is the first one invoked. It is the responsibility of each filter to invoke the next link in the chain; for example:
Notice how this filter invokes the 'next' instance before munging the content ... the far end of the chain is where the original IConduit reader is attached, so it will get invoked eventually assuming each filter invokes 'next'. If the next reader fails it will return IConduit.Eof, as should your filter (or throw an IOException). From a client perspective, filters are attached like this:
Again, the last filter attached is the first one invoked when a block of content is actually read. Each filter has two additional methods that it may use to control behavior:
The first method is invoked when the filter is attached to a conduit, while the second is invoked just before the conduit is closed. Both of these may be overridden by the filter for whatever purpose desired. Note that an input filter can choose to sidestep reading from the conduit (per the usual case), and produce its input from somewhere else entirely. This mechanism supports the notion of 'piping' between multiple conduits, or between a conduit and something else entirely; it's a bridging mechanism. Reimplemented in Conduit, and SocketConduit. |
|
Attach a filter to the IConduit output. The filter is invoked via its writer(void[]) method whenever a block of content is being written; the void[] array supplies writeable content. The filter should return the number of bytes it has actually consumed: less than or equal to the length of the provided array. Filters are chained together such that the last filter added is the first one invoked. It is the responsibility of each filter to invoke the next link in the chain; for example:
Notice how the filter invokes the 'next' instance after munging the content ... the far end of the chain is where the original IConduit writer is attached, so it will get invoked eventually assuming each filter invokes 'next'. If the next writer fails it will return IConduit.Eof, as should your filter (or throw an IOException). At the client level, filters are attached like this:
Again, the last filter attached is the first one invoked when a block of content is actually written. Each filter has two additional methods that it may use to control behavior:
The first method is invoked when the filter is attached to a conduit, while the second is invoked just before the conduit is closed. Both of these may be overridden by the filter for whatever purpose desired. Note that an output filter can choose to sidestep writing to the conduit (per the usual case), and direct its output to somewhere else entirely. This mechanism supports the notion of 'piping' between multiple conduits, or between a conduit and something else entirely; as with the input-filter case, this is a bridging mechanism. Reimplemented in Conduit, and SocketConduit. |
|
read from conduit into a target buffer Reimplemented in Conduit, and SocketConduit. Referenced by Conduit::copy(), Buffer::get(), Scanner::next(), and testHttpClient(). |
|
write to conduit from a source buffer Reimplemented in Conduit, and SocketConduit. |
|
Transfer the content of this conduit to another one. Returns true if all content was successfully copied. Reimplemented in Conduit, and SocketConduit. |
|
Flush buffer content out to this conduit. Returns true if all content is flushed; false if writing results in an Eof condition. Reimplemented in Conduit, and SocketConduit. Referenced by VersionMango::FileAppender::append(), FlushBuffer::copy(), Buffer::flush(), and Buffer::put(). |
|
Create a Buffer of a conduit-specific size Reimplemented in Conduit, FileConduit, and SocketConduit. Referenced by testHttpClient(). |
|
Returns true is this conduit can be read from Reimplemented in Conduit, and SocketConduit. |
|
Returns true if this conduit can be written to Reimplemented in Conduit, and SocketConduit. |
|
Returns true if this conduit is seekable (whether it implements ISeekable) Reimplemented in Conduit, and SocketConduit. |
|
Subclasses must implement closure mechanics. This is invoked when the number of close() invocations match that of aquire() -- the latter is typically called immediately following the successful construction of an IResource implementation; one should expect close to be required at least once. Reimplemented in Conduit, FileConduit, Resource, and Socket. |
|
Return the lock used by this resource Reimplemented in Resource. |
|
Set an alternate lock. Typically one would use this to synchronize multiple different Resources via a common object. Reimplemented in Resource. |
|
hold a reference to this resource. The caller is now responsible for invoking close() upon this resource; Reimplemented in Resource. |
|
If this resource is still open, acquire it and return true. This is a threadsafe test-and-set mechanism that fails only if the resource is already closed, or was never opened. Note that you are responsible for invoking close() whenever this method returns true. Reimplemented in Resource. |
|
release a reference to this resource Reimplemented in Resource. Referenced by HttpClient::close(), ConnectionPool::PoolConnection::close(), HttpBridge::cross(), ClusterThread::run(), and testClient(). |
|
conduit-specific reader Reimplemented in Conduit, ConduitSource, and SocketConduit. |
|
Reimplemented in Conduit, ConduitSource, and SocketConduit. Referenced by SocketConduit::attach(), and Conduit::attach(). |
|
Reimplemented in Conduit, ConduitSource, and SocketConduit. Referenced by SocketConduit::VersionUseFreeList::closure(), Conduit::closure(), and ConduitSource::unbind(). |
|
conduit-specific writer Reimplemented in Conduit, ConduitSink, and SocketConduit. |
|
Reimplemented in Conduit, ConduitSink, and SocketConduit. Referenced by SocketConduit::attach(), and Conduit::attach(). |
|
Reimplemented in Conduit, ConduitSink, and SocketConduit. Referenced by SocketConduit::VersionUseFreeList::closure(), Conduit::closure(), and ConduitSink::unbind(). |