0

USocket ライブラリで、本当に不可解な動作に遭遇しました。次のスニペットを検討してください。

    (defvar server-socket (usocket:socket-listen "localhost" 43593 
                                                 :element-type 
                                                 '(unsigned-byte 8)))

    (defvar client-connection (usocket:socket-accept server-socket))
    ;in a separate terminal, type "telnet localhost 43593".
    ;then type some text and hit enter.

    (listen (usocket:socket-stream client-connection))
    => NIL

なぜこうなった？へ:element-type '(unsigned-byte 8)の引数を省略するとusocket:socket-listen、問題なく動作します。任意のバイトを文字として表すことができないかどうかは理解できましたが (たとえば、utf-8 エンコーディングには無効なバイト シーケンスがあります)、逆 (バイトで表すことができない文字) は、特にネットワークでは意味がありません。環境。

(役立つ場合に備えて、Lubuntu 15.10、USocket 0.6.3.2 で clisp-2.49 を実行しています)。

4

1 に答える 1

0

listen問題は、ハイパースペック ( http://www.lispworks.com/documentation/HyperSpec/Body/f_listen.htm )のドキュメントで使用されている正確な表現にあったことが判明しました。

入力ストリームからすぐに利用できる文字がある場合は true を返します。それ以外の場合は false を返します。非インタラクティブな入力ストリームでは、listen は、ファイルの最後にある場合を除き、true を返します[1]。ファイルの終わりが検出された場合、listen は false を返します。listen は、input-stream がキーボードなどの対話型デバイスから文字を取得するときに使用することを目的としています。

を生成するように指示された場合、socket-streamは文字を生成しないため'(unsigned-byte 8)、読み取る準備ができているデータがあるかどうかに関係なく、ストリームlistenに戻ります。NIL

私の知る限りlisten、標準の文字以外の型に代わるものはありません。wait-for-input代わりにusocket を使用:timeoutし、ポーリングには 0 を設定します ( http://quickdocs.org/usocket/api )。

于 2015-12-05T23:48:25.310 に答える