Hi Long time ago I wrote a READ- and WRITE-SEQUENCE for CMUCL. I do not know if it has ever been included in the source code.
The code is probably not quite right at this point, but by looking at it, it seems that the function you are looking for is SYSTEM:OUTPUT-RAW-BYTES. Here is the code, just in case. Marco -- Binary/unsupported file stripped by Listar -- -- Type: application/octet-stream -- File: rw-sequence.lisp -- Attached file included as plaintext by Listar -- On Sep 23, 2004, at 2:57 PM, Russell McManus wrote: > > 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 > > -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A.
