World: r3wp

so you're struck after write ftp ["PASV"] ?

not stuck ... just at console

I have to a read after each write

yeah, i do that in the pop3 proto now as well

wouldn't even get the 'wrote event, otherwise

wait, i'll upload my current pop3 version

so, with the wait 1 in the wrote block  I can do this

cmd: open ftp://ftp.compkarori.com
read cmd
write cmd [ "PWD" ]
read cmd
write cmd [ "PASV" ]
read cmd

i do the following: in the write actor, i do write + read

in the read actor, i do a wait

the wait in the read actor returns once the awake handler in the 
tcp subport returns true

here's yours http://rebol.wik.is/Rebol3/Schemes/Pop

here's the current version: http://bolka.at/share/prot-pop3.r[temporary 
url]

which is heavily restructured, now also allowing you to use custom 
commands directly

write/lines pop3 ["TOP 1 10"]
to-string read pop3

hehe .. you changed your mind!

sure :)

and i even tested it with a win32 rebol3 :)

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 :(