World: r3wp
[!REBOL3 Schemes] Implementors guide
older newer | first last |
Andreas 11-Jan-2010 [1120x2] | ok, still. long wait after SYST |
then after 227 PASV | |
Graham 11-Jan-2010 [1122] | yes ... shouldn't happen |
Andreas 11-Jan-2010 [1123] | ah, i think the culprit is that you WAIT inside the awake handler |
Graham 11-Jan-2010 [1124] | I guess that's a no no ... |
eFishAnt 11-Jan-2010 [1125] | wow, you guys are rockin! Thanks Steeve, for the dns2. Funny, that's how my wife says my name when she wants something..."Oh Steeeeve." |
Andreas 11-Jan-2010 [1126] | someone said so, yes :) |
Graham 11-Jan-2010 [1127] | so fish .. where's your codec ?? |
Andreas 11-Jan-2010 [1128] | but changing the WAIT inside the awake to a READ doesn't change things :) |
Graham 11-Jan-2010 [1129] | a system read? |
Andreas 11-Jan-2010 [1130] | unless you do something special, there's only system reads for tcp ports |
Graham 11-Jan-2010 [1131] | no binding for me |
Andreas 11-Jan-2010 [1132x2] | even for the scheme port, there's only system read |
but the system then dispatches this to the read actor | |
Graham 11-Jan-2010 [1134] | and my read actor does a wait |
Andreas 11-Jan-2010 [1135x2] | yeah, but inside wait-cmdport you're WAITing on the cmdport |
inside write-cmdport* | |
Graham 11-Jan-2010 [1137] | fix it please :) |
Andreas 11-Jan-2010 [1138x4] | change line 212 from `wait cmdport` to `read cmdport` |
doesn't fix the long lags, though | |
in fact, you can drop this line completely, i think | |
because a WRITE on the tcp port from within the tcp port's awake handler automatically re-schedules the tcp port for event handling | |
Graham 11-Jan-2010 [1142] | ok, working with line removed .. but still delays |
Andreas 11-Jan-2010 [1143x12] | mhm |
only chasing thru your code, atm :) | |
ok, the flow should be, imho: - read WAITs on the cmdport - if the cmdport needs to open a dataport, cmdport WAITS on dataport | |
port/state/connection is your cmdport, if i'm not mistaken | |
so i started by changing the read actor to: read: func [port [port!]] [ wait port/state/connection ] which should break things hard :) | |
and yes it does, hangs after SYST | |
next step: tracing if your awake handler returns true in this case | |
wuah, huge switch :) | |
but, as expected, it does not :) | |
client/spec/ready seems to be a good flag to use as return value for the awake handler | |
unfortunatly, in the AUTH 230 handler, you set both ready to true _and_ issue another write | |
assuming that the SYST is rather worthless anyway, i drop the write | |
Graham 11-Jan-2010 [1155] | ready is set to true so I can process the SYST |
Andreas 11-Jan-2010 [1156] | i'll abuse ready is the return value from the awake handler, for now :) |
Graham 11-Jan-2010 [1157] | I did this as otherwise I ended up pipelining the ftp server :( |
Andreas 11-Jan-2010 [1158] | don't they like that :) ? |
Graham 11-Jan-2010 [1159] | not if they don't support pipelining! |
Andreas 11-Jan-2010 [1160x2] | :) |
btw graham, do you happen to have heard of git? | |
Graham 11-Jan-2010 [1162] | repository thingy? |
Andreas 11-Jan-2010 [1163x2] | yep |
used it, by any chance? | |
Graham 11-Jan-2010 [1165x2] | yes :) |
nope ... | |
Andreas 11-Jan-2010 [1167] | wow, fixed it :) |
Graham 11-Jan-2010 [1168] | Umm... does Ubuntu use git ?? |
Andreas 11-Jan-2010 [1169] | i use git |
older newer | first last |