World: r3wp
[!REBOL3 Schemes] Implementors guide
older newer | first last |
Andreas 9-Jan-2010 [738x4] | 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 [773x2] | 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 | |
Graham 9-Jan-2010 [775] | read reads a max of 32,000 bytes ... so does this mean if more data is coming, another read will be triggered? |
Andreas 9-Jan-2010 [776x4] | 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 :) | |
Graham 9-Jan-2010 [780x3] | 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 # | |
Andreas 9-Jan-2010 [783] | interesting, thanks |
Graham 9-Jan-2010 [784x4] | 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. | |
older newer | first last |