On 29/04/2007, at 12:35, Maxim Olivier-Adlhoch wrote:
> hi,
>
> it just tests if its none I guess. its just more readable than "if
> none?
> port" I actually receive the handler with a port set to none some
> times!
Yes, I've seen this too and I think it had something to do with a
race condition: The client sends X amount of data, the server reads
some of it, but the rest is lost and then the port is locked to a
none! output.
It's pretty darned frustrating that these errors only occur, even
reliably, with complex code like Rugby. There are at least two port
bugs easily visible this way, but they are impossibly hard to
recreate outside Rugby.
> the attempt is to make sure the sub port is also open, and to make
> sure
> there is no lingering error within the handler... which is what
> seems to
> make the port do a hard crash (well, the only way I can explain it).
Well, I hoped I could use it to check for a dead port, but it seems
to make no difference:
if dest [
length: write-io dest msg length? msg ; <-- this hangs on
console escape
]
It hangs anyway.
Using the aforementioned attempt on close makes Rugby very unstable
and stops responding after 3-4 requests, but I don't really think
it's possible to apply the attempt close to that code.
--
Regards,
Henrik Mikael Kristensen
--
To unsubscribe from the list, just send an email to
lists at rebol.com with unsubscribe as the subject.
