Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #517 (closed defect: fixed)

Opened 12 years ago

Last modified 12 years ago

Conduit filters aren't fully implemented

Reported by: Deewiant Assigned to: kris
Priority: major Milestone: 0.99 RC3
Component: IO Version: trunk
Keywords: Cc: deewiant@gmail.com

Description

As described, for instance, in this comment of kris's in Ticket 353, Conduit filters are attached via the IConduit.attach methods and their read/clear (for InputStreams?) or write/copy/flush (for OutputStreams?) methods are called by the Conduit. Then the filters can either call the next filter's methods in turn or hijack the input/output completely.

However, filters do not seem to be used at all:

import tango.io.Stdout;
import tango.io.model.IConduit;

class KillStream : OutputStream {
	override IConduit     conduit()            { assert (0); }
	override void         flush  ()            { assert (0); }
	override OutputStream copy   (InputStream) { assert (0); }
	override size_t       write  (void[])      { assert (0); }
}

void main() {
	Stdout.stream.conduit.attach(new KillStream));
	Stdout("I live!").newline;
}

The above code should result in an assertion failure, but doesn't: none of the KillStream?'s methods are called, and "I live!" is output.

In addition, it's unclear how to invoke the next filter from any of the above methods.

Change History

07/02/07 19:15:02 changed by kris

  • status changed from new to assigned.

Sorry ... I complete lost track of this one.

Filters are expected to capture and invoke their ancestor appropriately. It's done this way so that filters can 'redirect' the IO if they wish (break the chain).

The problem occurring with the example is that there a buffer in between the Stdout conduit and the usage of Stdout itself. The buffer was attached to the conduit long before the filter was, and thus doesn't see the additional filter when that is added.

This needs to be resolved internally somehow. Doing a setConduit() on the buffer would resolve the problem, but Stdout.buffer is no longer directly exposed (would need a cast). C'est la vie

Sorry it took so long to respond

07/10/07 04:51:03 changed by kris

  • status changed from assigned to closed.
  • resolution set to fixed.
  • milestone set to 0.99 RC3.

fixed in [2434]

thanks, and my apologies for the long delay