Eric Marsden <[EMAIL PROTECTED]> writes: >>>>>> "rm" == Russell McManus <[EMAIL PROTECTED]> writes: > > rm> I think that write-sequence is specified to write the entire > rm> sequence before it returns, which might not be possible when > rm> writing to a network stream without blocking, and entering into > rm> a recursive SERVE-EVENT, which I am trying to avoid. > > I don't think that WRITE-SEQUENCE will reenter SERVE-EVENT. The > buffering mechanism in CMUCL's fd-streams will postpone writes if > they would block (see DO-OUTPUT-LATER in code/fd-streams.lisp of the > CMUCL source code). > > It's not clear that this is the best possible mechanism, since > errors that occur during postponed output will not be signaled from > within WRITE-SEQUENCE, but rather from the next operation that > entered SERVE-EVENT. I agree that a function that can do partial > writes in non-blocking mode would be useful; hopefully a well though > out API will emerge from the streams-standard discussion that > started at Bordeaux this year. > > For now I'd expect that you will obtain the best results by using > WRITE-SEQUENCE on sequences around the same size as your output > stream's buffer. It might also be useful to increase the size of the > stream's buffers, but I haven't run any experiments on this.
Thanks for taking the time to respond. I guess I should have read the source code to write-sequence before posting. Of course, I have already tried numerous variations on how to get the behavior I want out of CMUCL, and based on my experiments so far, I don't think that your suggestion will address the problem. However I do think that a 'write-n-bytes' function analogous in behavior to 'read-n-bytes' would be really spiffy, and I think address the issue completely. Perhaps I'll read fd-streams.lisp and try to write the necessary function myself. -russ
