World: r3wp

and one of the things i observed is that the tcp port does not seem 
to get re-scheduled after a write

i.e. i do a write on the tcp port, later on i wait on the tcp port, 
but no the wrote event never occurs

which lead me to conclude that if i want any network interaction 
to occur on the tcp port, be it sending data that was buffered with 
write earlier, or listening for incoming data, i have to tell R3 
that by doing a read on the tcp port

how does this work?

switch event/type bind

the _only_ exception seems to be when the tcp port is not yet connected

then a read on the not-connected port raises an error, so in this 
case a simple wait is enough

Yeah .. I think that is what I am observing ...

(i'll get to the bind in a second, bear with me)

the second observation is that the return value of an awake handler 
seems to have no effect at all on scheduling

but influences when a WAIT on the port will return

a WAIT on the tcp port returns once the awake handler returns true; 
for any other return value, the WAIT keeps hanging on

so in essence: write only buffers data to be sent, read schedules 
a port so that it awakes on events, wait blocks until awake returns 
true

You can only exit the awake handler by returning true ...

need a diagram to understand this ...

and if you want for the awake handler to be called again, you need 
to be sure to read event/port

i think you can easily cause a deadlock this way

WAIT on a port

this blocks on ports that were scheduled with read earlier on

now somewhen the awake handler will get called

return false from the awake handler, but do _not_ re-schedule the 
port

voila, you're deadlocked

the WAIT will keep on blocking, but the port was not re-scheduled 
with a read, so the awake handler will never be called again

wait [ port timeout ]

yes, as a user :)

as a scheme author, we have to be careful to avoid those deadlocks

to i think, awake should only finish with one of the following sequences:
1.) read event/port return false
2.) return true

except for 'lookup and 'close events, of course

re the bind: i store the stuff the awake handler needs in order to 
work in port/locals

as a context. with the bind i can make those values appear as if 
they were local words, i.e. buffer refers to event/port/locals/buffer

... ah ... I missed the client/locals there ...

when the second parameter to a function is more than 10 lines down 
the page ... .it escapes my eye!

yep, it's not that i'd consider it good style anyway ...

this world is playing busy again :(

http://www.rebol.net/wiki/TCP_Port_Details

very low-level, most of it a bit below our concerns :)

but it's good to know that we don't have to take care of partial 
writes

read reads a max of 32,000 bytes ... so does this mean if more data 
is coming, another read will be triggered?

yes

and i don't think that the 32,000 bytes given in this document are 
realistic

tcp packet size is typically limited to 1500 bytes, so for any significant 
transfer many 'read events will occur

but maybe the "Note: not 32K" comment wants to tell us that the default 
buffer size is 32 :)

I see that the buffer is shared for both reading and writing

A few issues a couple of years old http://www.rebol.net/wiki/Ports_and_Schemes:_Issues#Issue_4:_WAIT

remove the #

interesting, thanks

Managed to get a directory listing with my ftp scheme :)

Things are definitely looking up ....

a directory is just a file .. so this means I have file transfer 
"working "

Just looking at what R2 does .. .each time it does a file/directory 
transfer, it opens the data connection, sends the command and then 
closes it again.

Hmm. I did a LIST and only got 4000 characters back.  I tried it 
again, but delayed the read a bit longer and got the full 8000 characters 
or so.  So, wonder why the data arrriving is not triggering the read 
event