[REBOL] Re: How do I? Know when a tcp port is empty?
From: petr:krenzelok:trz:cz at: 24-Oct-2000 13:25
Andrew Martin wrote:
> How do I? Know when a _tcp_ port is empty?
> Here's a section of my code loosely copied and combined from the Rebol
> WebServer and Langreiter's vanillean http://www.langreiter.com
> Listen: port!
> Connection: port!
> Stop: false
> set 'Web-Server function [
> Port [integer!] Web [file!]
> Request Filename Data
> Listen: open/lines join tcp://: Port
> while [not Stop] [
> Connection: first wait Listen
> Request: make string! 1024
> repend Request [first Connection newline]
> while [not 1 = length? Connection/state/inBuffer] [
> ; the above line disturbs me seriously...
> repend Request [first Connection newline]
> print Request
> Using lines such as:
> empty? Connection
> seems to lead to infinite loops.
> Can some one point me in the right direction please?
Hasn't Holger already suggested using 'copy, when 'copy return empty string if
there is no info available?
Hmm, maybe one of older Holger's mails could help here?
Please wait for the next experimental build (i.e. a version AFTER
Core 2.4.34, View 0.10.25 or Command 0.6.12) before publically releasing
any scripts that use the new non-blocking features in REBOL, because
we need to change the behavior (again), for better compatibility with
older scripts, and to avoid future legacy problems, This change will
break scripts that rely on the behavior in the current exp-build.
The changes are: copy on TCP ports opened without refinements will work
the way it used to originally (i.e. block if there is no data). If you
don't want copy to block then use /no-wait on the open call. This means
instead of a /wait refinement there will be a /no-wait refinement,
and the default behavior will be reversed compared to the current
exp-build, and thus will be the same way it used to be in Core <= 2.3
The main reason is that with this change scripts which loop on copy
until it returns none will continue to work on new versions of REBOL,
without adapting the script.
Also, if there is no data then copy will return an empty series, not
none, as it does in current exp-builds, allowing you to distinguish the
no data available yet, would block
case from an end of stream, i.e.
the peer closing the connection (for which copy will still return none).
There will also be some changes to wait to make it more useful, e.g.
wait [0 port] will poll the port (i.e. return the port if there is
data, and none otherwise). This also works with multiple ports.
Old versions of Core already used to do this on some platforms,
somewhat inofficially, but current versions don't. It will become
an official feature on all platforms starting with the next
experimental build. There will also be a new "/all" refinement
to wait which causes wait to return a block of all ports that have
data waiting (instead of returning just one port). This allows you
to write your own scheduler (e.g. round-robin) for handling incoming
data on a multiplexed server written in REBOL.
We are also planning other enhancements to wait and ports in general
in the future, to make it easier to handle interactive, asynchronous
connections, to support asynchronous sending, asynchronous connecting,
asynchronous accepting of connections, asynchronous UDP operation,
and to simplify the handling of multiple connections at the same time,
e.g. for downloads in the background and for multiplexed web/ftp
servers. Lots of good stuff ahead :).
Please avoid using read-io whenever possible. It is a very low-level
function that exposes your script to operating system-dependent
oddities. For instance the amount of data typically returned may vary
with the operating system, making testing more difficult for you. You
also lose the convenience of line feed conversion etc., which may cause
unexpected problems with your script when moving between Windows and
Unix machines. "Normal" port functions in REBOL (copy, insert etc.)
do these things automatically for you.
We realize that in the past some shortcomings in the "normal" port
functions (in particular copy blocking) have prevented you from doing
some useful things, and sometimes read-io seemed to help, but these
issues should be resolved in the next exp builds, and then the use of
read-io will be discouraged even more than it is now.
And just in case you are wondering, those new port features together with
work on some additional enhancements in VID are the reasons why the
new exp build for View we promised earlier is not out yet -- sorry for
that delay. RSN, really...