Re: [Help-smalltalk] ZLib streams

[Robin Redeker]

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