tags:

views:

634

answers:

2

I want to run a background task that reads input from a TextReader and processes it a line at a time. I want the background task to block until the user types some text into a field and clicks the submit button. Is there some flavour of TextReader that will block until text is available and lets you somehow add more text to the underlying source?

I thought that a StreamReader and StreamWriter pointing to the same MemoryStream might work, but it doesn't seem to. The StreamReader sees that the MemoryStream is empty at the start, and never checks again.

I realize that it would be easier to write a ProcessLine() method and call it whenever the user clicks the submit button. However, I'm trying to design a plug-in architecture, and I'd like the plug ins to look like old-fashioned console apps with an input stream and an output stream. I want the plug in's input stream to just block until the user clicks the submit button with some input text.

+5  A: 

I think you'd be much better off creating an event in your main application that is raised when the user hits Submit. The text data would be passed in the event args. Each plugin registers an event handler for the event, and handles the data passed in when the event is raised. This allows many plugins to process the data from a single submission without a lot of plumbing work on your part, and means the plugins are able to just sit idle until the event is raised.

Harper Shelby
It's just so much simpler for the plug-in writer to write "do { line = reader.ReadLine(); ... }while(line != null);" than it is to register for an event.
Don Kirkby
Perhaps that bit of code is simpler, but setting up the streams properly is much trickier. You either have a one writer/multiple readers problem, or a communications setup issue. The Event architecture for .NET is really designed for this sort of situation, and handles it well.
Harper Shelby
You're absolutely right, but I'm writing the infrastructure, and our customers are writing the plug ins. I want to make it simple for them.
Don Kirkby
I still believe the Event architecture is better - I don't believe I'm a genius programmer, and it didn't really take me long to figure out writing event handlers. Writing *correct* named pipe or socket handling code is a lot harder IMHO.
Harper Shelby
+2  A: 

It seems that there is no implementation of this - which is strange, since I agree that it would be a useful construct. But it should be simple to write. Something like this should work:

  public class BlockingStream: Stream
  {
    private readonly Stream _stream;

    public BlockingStream(Stream stream)
    {
      if(!stream.CanSeek)
        throw new ArgumentException("Stream must support seek", "stream");
      _stream = stream;
    }

    public override void Flush()
    {
      lock (_stream)
      {
        _stream.Flush();
        Monitor.Pulse(_stream);
      }
    }

    public override long Seek(long offset, SeekOrigin origin)
    {
      lock (_stream)
      {
        long res = _stream.Seek(offset, origin);
        Monitor.Pulse(_stream);
        return res;
      }
    }

    public override void SetLength(long value)
    {
      lock (_stream)
      {
        _stream.SetLength(value);
        Monitor.Pulse(_stream);
      }
    }

    public override int Read(byte[] buffer, int offset, int count)
    {
      lock (_stream)
      {
        do
        {
          int read = _stream.Read(buffer, offset, count);
          if (read > 0)
            return read;
          Monitor.Wait(_stream);
        } while (true);
      }
    }

    public override void Write(byte[] buffer, int offset, int count)
    {
      lock (_stream)
      {
        long currentPosition = _stream.Position;
        _stream.Position = _stream.Length;
        _stream.Write(buffer, offset, count);
        _stream.Position = currentPosition;
        Monitor.Pulse(_stream);
      }
    }

    public override bool CanRead
    {
      get
      {
        lock (_stream)
        {
          return _stream.CanRead;
        }
      }
    }

    public override bool CanSeek
    {
      get
      {
        lock (_stream)
        {
          return _stream.CanSeek;
        }
      }
    }

    public override bool CanWrite
    {
      get
      {
        lock (_stream)
        {
          return _stream.CanWrite;
        }
      }
    }

    public override long Length
    {
      get
      {
        lock (_stream)
        {
          return _stream.Length;
        }
      }
    }

    public override long Position
    {
      get
      {
        lock (_stream)
        {
          return _stream.Position;
        }
      }
      set
      {
        lock (_stream)
        {
          _stream.Position = value;
          Monitor.Pulse(_stream);
        }
      }
    }
  }
Rasmus Faber
Thanks, I did something similar to this, but at the Reader level. This looks more flexible.
Don Kirkby
I implemented this, and it worked well. One gotcha: if you're hooking up a StreamReader and a StreamWriter to the BlockingStream, turn on AutoFlush on the writer.
Don Kirkby