Dear Marc,
How do I know if a device port reached EOF?
Is there a flag internally in Gambit somewhere I suppose there is a flag internally somewhere in Gambit that keeps track of this. |wait-for-input|just returns immediately. Of course I could do something like (read-subu8vector v 0 1 port 0) though in this particular application I'd much prefer to only do the socket reading and writing completely outside the scope of Gambit's IO system.
If it's not in Gambit then please just say so, there's always another implementation path, though I'd appreciate not to go into higher complexity than needed.
Thanks!
(define (port-wait-for-input port) (##wait-for-io! (device-port-rdevice-condvar port) (port-rtimeout port)))
Afficher les réponses par date
Oh dear, some things are surprisingly enough impossible to do in standard Unix API:s: the *only* way to know if there's EOF is to actually do a read of > 0 bytes.
(> 0 because 0 is the return value that signals EOF, eh.)
select() on a closed socket instantaneously returns read-ability so this must be the basis for port-wait-for-input's behavior, which is really fine of course.
That Unix API was clearly not made with even quite basic application-level abstraction of socket access in mind.
Very well, I suppose you always learn something new every day.
Thanks, Mikael
Dear Marc,
How do I know if a device port reached EOF?
Is there a flag internally in Gambit somewhere I suppose there is a flag internally somewhere in Gambit that keeps track of this. |wait-for-input|just returns immediately. Of course I could do something like (read-subu8vector v 0 1 port 0) though in this particular application I'd much prefer to only do the socket reading and writing completely outside the scope of Gambit's IO system.
If it's not in Gambit then please just say so, there's always another implementation path, though I'd appreciate not to go into higher complexity than needed.
Thanks!
(define (port-wait-for-input port) (##wait-for-io! (device-port-rdevice-condvar port) (port-rtimeout port)))
On Tue, Nov 20, 2012 at 03:38:02AM +0200, Mikael wrote:
Oh dear, some things are surprisingly enough impossible to do in standard Unix API:s: the *only* way to know if there's EOF is to actually do a read of > 0 bytes.
Which may well have been the way sequential hardware worked way back in the 70's.
This is one of the few new things that Pascal got right -- that you should ask whether eof is false before you read. On recalcitrant OSes (most of them) this had to be implemented by reading into a buffer for the eof test, which led to confusing interactive behaviour of straightforward-looking programs.
eof had an unobvious side effect.
(> 0 because 0 is the return value that signals EOF, eh.)
select() on a closed socket instantaneously returns read-ability so this must be the basis for port-wait-for-input's behavior, which is really fine of course.
That Unix API was clearly not made with even quite basic application-level abstraction of socket access in mind.
There was a serious attempt to define the 'software bus', a serious attempt to design a logically organised interface to the OS. It was pushed by the Japanese through the ISO standadisation process, but failed against determined U.S.A. opposition. They wanted the UNIX interface to be the standard,m and, ultimately, POSIX was the result.
-- hendrik
Very well, I suppose you always learn something new every day.
Thanks, Mikael
Dear Marc,
How do I know if a device port reached EOF?
Is there a flag internally in Gambit somewhere I suppose there is a flag internally somewhere in Gambit that keeps track of this. |wait-for-input|just returns immediately. Of course I could do something like (read-subu8vector v 0 1 port 0) though in this particular application I'd much prefer to only do the socket reading and writing completely outside the scope of Gambit's IO system.
That flag was there in Pascal. But, as I've mentioned, its effective use is sabotaged by most OS designs.
-- hendrik
To know if you have reached EOF you need to attempt a read. If you read with read-char/peek-char you will get #!eof. If you use read-subu8vector the result will be 0 on reaching EOF.
Marc
On 2012-11-19, at 1:21 PM, Mikael mikael.rcv@gmail.com wrote:
Dear Marc,
How do I know if a device port reached EOF?
Is there a flag internally in Gambit somewhere I suppose there is a flag internally somewhere in Gambit that keeps track of this. |wait-for-input| just returns immediately. Of course I could do something like (read-subu8vector v 0 1 port 0) though in this particular application I'd much prefer to only do the socket reading and writing completely outside the scope of Gambit's IO system.
If it's not in Gambit then please just say so, there's always another implementation path, though I'd appreciate not to go into higher complexity than needed.
Thanks!
(define (port-wait-for-input port) (##wait-for-io! (device-port-rdevice-condvar port) (port-rtimeout port)))
-
Hendrik Boom -
Marc Feeley -
Mikael