r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 Schemes] Implementors guide

Graham
9-Jan-2010
[724]
I have to a read after each write
Andreas
9-Jan-2010
[725x3]
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
Graham
9-Jan-2010
[728]
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
Andreas
9-Jan-2010
[729x3]
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
Graham
9-Jan-2010
[732]
here's yours http://rebol.wik.is/Rebol3/Schemes/Pop
Andreas
9-Jan-2010
[733x3]
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
Graham
9-Jan-2010
[736]
hehe .. you changed your mind!
Andreas
9-Jan-2010
[737x5]
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
Graham
9-Jan-2010
[742]
how does this work?

switch event/type bind
Andreas
9-Jan-2010
[743x2]
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
Graham
9-Jan-2010
[745]
Yeah .. I think that is what I am observing ...
Andreas
9-Jan-2010
[746x5]
(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
Graham
9-Jan-2010
[751x2]
You can only exit the awake handler by returning true ...
need a diagram to understand this ...
Andreas
9-Jan-2010
[753x8]
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
Graham
9-Jan-2010
[761]
wait [ port timeout ]
Andreas
9-Jan-2010
[762x6]
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
Graham
9-Jan-2010
[768x2]
... 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!
Andreas
9-Jan-2010
[770]
yep, it's not that i'd consider it good style anyway ...
Graham
9-Jan-2010
[771x2]
this world is playing busy again :(
http://www.rebol.net/wiki/TCP_Port_Details
Andreas
9-Jan-2010
[773]
very low-level, most of it a bit below our concerns :)