World: r3wp
[!REBOL3 Schemes] Implementors guide
older newer | first last |
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 :) |
older newer | first last |