[4922] in testers
Re: possibly-relevant fix to an ORBit bug
daemon@ATHENA.MIT.EDU (Larry Stone)
Thu Jun 28 18:12:49 2001
Date: Thu, 28 Jun 2001 18:12:46 EDT
From: Larry Stone <lcs@MIT.EDU>
Reply-To: <lcs@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
Cc: testers@MIT.EDU
In-Reply-To: Your message of Thu, 28 Jun 2001 17:57:35 -0400
Message-ID: <CMM.0.90.4.993766366.lcs@defiant.mit.edu>
> Hi, I'm sorry I dropped this on the floor for a while.
>
> I don't think we're currently experiencing problems from this bug, but
> we might be, and it sounds like nautilus will definitely run into it.
> I will clean up this patch and submit it to source-reviewers. (If
> you're curious, I plan to (a) clean up the indentation,
I think it's consistent with the wacky style in the ORBit code, but no
big deal.
(b) remove the
> switch to blocking mode optimization since we should only be in the
> business of debugging,
The blocking mode isn't an optimization, it would have to be replaced
with equivalent code to use polling. ORBit 0.5 is not really asynchronous
or multithreaded, it just has bits of code that might make you think so.
AFAIK, it uses nonblocking I/O to get the lowest possible latency, and
reverts to blocking I/O when necessary. It could be a broken concept
but I was trying to change as little as possible.
(c) eliminate the use of alloca, since it's a
> portability hazard, and
Don't do this, it will create a leak. They use alloca because those
buffers are never freed. It's not a portability problem for ORBit
because the rest of ORBit and its generated RPC code depend heavily on
alloca.
-- Larry
