Оценката на потока ReadWrite на Smalltalk приEND няма ефект

Оценявам следния блок:

[byteStream atEnd] whileFalse: [stream nextPut: self parsePacket] 

Проблемът е, че моят "byteStream", който е поток ReadWrite, е в края си (проверявам го и позицията = ограничението за четене = ограничението за запис = 512) и цикълът ми не спира, както ако: " [ byteStream atEnd] " няма ефект. Използвам VisualWorks 7.9.1 под linux и моят byteStream се захранва чрез UDP Socket. Всяка помощ е добре дошла.

Ето кода на сървъра:

listenOnPort: aPort
| server peerAddr |
self initialize.
server := SocketAccessor newUDPserverAtPort: aPort.
peerAddr := IPSocketAddress hostName:'localhost' port: aPort.
process := 
        [
        [| buf sizeOfBuf |
        buf := String new: 2048.
        sizeOfBuf := server bufferSize.
        sizeOfBuf > 0
            ifTrue: 
                [| dataStream |
                server readWait.
                server receiveFrom: peerAddr buffer: buf.
                dataStream := ReadStream on: buf from: 1 to: sizeOfBuf.
                dataStream reset.
                self receive: dataStream]]
                repeat.]
                fork.

Ето кода, който анализира това, което се съдържа в буфера:

parse
^ Array streamContents: [:stream |
    [byteStream atEnd] whileFalse: [stream nextPut: self parsePacket] 
        ]

Проблемът е цикълът в метода за анализиране, пробвах кода на Windows XP 32bit и работи добре, но на Linux 32bit не, мисля, че има нещо общо с UDP мрежата на OS?


person SolidSnake87    schedule 08.04.2013    source източник
comment
Затворен ли е контактът, когато цикълът продължава?   -  person User    schedule 08.04.2013
comment
Можете ли да ни покажете повече от кода? Това може да ни помогне да разберем по-добре проблема и къде може да е проблемът.   -  person Dave Newman    schedule 08.04.2013
comment
Сокетът не е затворен, но буферът е в границата за четене.   -  person SolidSnake87    schedule 09.04.2013
comment
@Dave, редактирах въпроса. Програмата е предназначена да анализира отворените съобщения за управление на звука, но не мога да публикувам целия код, твърде голям.   -  person SolidSnake87    schedule 09.04.2013
comment
@SolidSnake87 Изтеглих пробното копие на VisualWorks. Ще видя дали мога да създам прост случай, който възпроизвежда това на Linux. Исках да потвърдя, че byteStream от parse е същият поток като dataStream от listenOnPort:, нали?   -  person Dave Newman    schedule 09.04.2013


Отговори (2)


Открих откъде идва проблемът. Преоразмерявах буфера си с метод, който анализира размера на OSC BUNDLE, но този метод беше дефектен и всеки път изпращаше "0" като позиция към буфера. така че всеки път, когато цикълът намира буфера в първоначалната му позиция и след това продължава цикъла, което е логично. Благодаря ти за помощта.

person SolidSnake87    schedule 10.04.2013
comment
Радвам се, че го намерихте. Не можах да продължа това. Версията на VisualWorks, която изтеглих, дори нямаше метода streamContents: никъде в основното изображение. - person Dave Newman; 10.04.2013
comment
А, да, прав си, не е включено в основното изображение, защото аз го написах, но както звучи, връща съдържанието на потока само по този начин: streamContents: aBlock | stream | stream := self new writeStream. aBlock value: stream. ^stream contents - person SolidSnake87; 11.04.2013
comment
Това, което ме хвърли, беше, когато търсих в уебсайта на VisualStream, streamContents: беше използван в много примери и публикации във форуми. Мислех, че е в някой от колетите, но не можах да определя в кой. :) - person Dave Newman; 11.04.2013

Какво имаш предвид под "цикълът продължава"? Ясно е, че не може да продължи да чете пакети, които не са там. Възможно ли е тъй като сте поставили твърдо кодирано ограничение за размера на буфера, че имате пакет в края на буфера, който е незавършен, поради което той не успява да се опита да прочете останалата част от него?

person Martin Kobetic    schedule 09.04.2013