[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] ZLib streams
From: |
Robin Redeker |
Subject: |
Re: [Help-smalltalk] ZLib streams |
Date: |
Thu, 23 Aug 2007 14:55:42 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
On Thu, Aug 23, 2007 at 09:55:30AM +0200, Paolo Bonzini wrote:
>
> >Would it be possible to prevent the call to fillBuffer to not have
> >a blocking RawInflateStream creation and only have it block when _I_
> >call RawInflateStream>>#nextHunk?
>
> Seems easy...
>
>
> --- orig/packages/zlib/ZLibReadStream.st
> +++ mod/packages/zlib/ZLibReadStream.st
> @@ -145,9 +145,9 @@ position
> !ZlibReadStream methodsFor: 'private'!
>
> resetBuffer
> + ptr := 0.
> delta := 0.
> - endPtr := 0.
> - self fillBuffer!
> + endPtr := 0!
>
> initialize: aStream
> super initialize: aStream.
Ok, thats easy. But maybe a bit too easy :-)
That worked for my small example. But I've tried to implement it in my program
now and ran into some other problem:
[socket atEnd not] whileTrue: [self handleData: inputStream nextHunk]
(Please note that I tried to use '[inputStream atEnd not]' first, but that
seemed to run into the same problem I'm going to describe below as a
call to ZlibReadStream>>#atEnd results in a call to ZlibReadStream>>#fillBuffer)
nextHunk does not seem to return properly. I guess the problem is in
ZlibReadStream>>#fillBuffer:
"Fill the output buffer, supplying data to zlib until it can actually
produce something."
| flush |
delta := delta + endPtr.
ptr := 0.
[
inBytes isNil ifTrue: [
inBytes := self stream atEnd
ifTrue: [ #[] ]
ifFalse: [ self stream nextHunk ] ].
flush := self stream atEnd ifTrue: [ 4 ] ifFalse: [ 0 ].
endPtr := self processInput: flush size: inBytes size.
endPtr = 0 ] whileTrue.
"End of data, or zlib error encountered."
endPtr = -1 ifTrue: [ self checkError ]! !
The following line completes when it received the syncFlushed data,
and an inspect revealed that there really was data.
ifFalse: [ self stream nextHunk ] ].
However, I put in some displayNls and observed that the call:
flush := self stream atEnd ifTrue: [ 4 ] ifFalse: [ 0 ].
Seemed to block. That wouldn't be a problem if there would be further
data waiting now, but it isn't (due to the fact that the first packet was a
'HELO' in my protocol and my software waits now for further input which
wont come).
You may also note that the call to ZlibReadStream>>#processInput:size: which
will result in a call to RawInflateStream>>#processInput:size: will receive the
wrong flag (0 Z_NO_FLUSH or 4 Z_FINISH, and not 2 Z_SYNC_FLUSH) when atEnd
finally returns.
I'm not familiar enough and currently don't have enough time to try to fix it
or propose a solution to this.
Robin