Поток ReadWrite в Smalltalk при оценке END не действует.

Я оцениваю следующий блок:

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

Проблема в том, что мой " byteStream ", который является потоком ReadWrite, находится в конце (я проверяю его и позиция = предел чтения = предел записи = 512), и мой цикл не останавливается, например, если: "[ byteStream atEnd]» не имело никакого эффекта. Я использую VisualWorks 7.9.1 под Linux, и мой byteStream передается через сокет UDP. Любая помощь приветствуется.

Вот код сервера:

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] 
        ]

Цикл в методе синтаксического анализа - это проблема, я попробовал код на 32-битной Windows XP, и он работает нормально, но на 32-битной Linux это не так, я думаю, это как-то связано с сетью UDP ОС?


udp stream smalltalk visualworks
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
@ Дэйв, я отредактировал вопрос. Программа предназначена для разбора сообщений открытого управления звуком, но я не могу выложить весь код, слишком большой.   -  person SolidSnake87    schedule 09.04.2013
comment
@SolidSnake87 Я скачал оценочную копию VisualWorks. Я посмотрю, смогу ли я создать простой случай, воспроизводящий это в Linux. Я хотел подтвердить, что byteStream из parse — это тот же поток, что и dataStream из listenOnPort:, да?   -  person Dave Newman    schedule 09.04.2013

Ответы (2)


arrow_upward
1
arrow_downward

Я обнаружил, откуда возникла проблема. Я изменял размер своего буфера с помощью метода, который анализирует размер 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

arrow_upward
0
arrow_downward

Что вы подразумеваете под "цикл продолжается"? Ясно, что он не может продолжать читать пакеты, которых нет. Возможно ли, что, поскольку вы жестко запрограммировали ограничение на размер буфера, у вас есть незавершенный пакет в конце буфера, поэтому он не пытается прочитать остальную часть?

person Martin Kobetic    schedule 09.04.2013