Re: [Chromium-dev] tcpip problems, why is default behavior non-blocking suddenly?

[Mike H. <mho...@gr...>]

Actually, it seems like the correct thing to do would be to not return on 
a recv=0 but to enter a yeild loop in the threaded case.  This way the 
semantics would stay the same for the function as they used to be and the 
thread issues should be okay.

-Mike

On Fri, 28 Jun 2002, Alan Hourihane wrote:

> On Thu, Jun 27, 2002 at 09:04:15AM -0700, Mike Houston wrote:
> > Well, maybe we should just provied two methods, one that blocks and one 
> > that doesn't.  How does that sound?
> > 
> > We should probably have a further discussion about the change.  I'm a 
> > little worried about the effects the current code will have on some 
> > things.  For example, in the general case, there is not a retry on a 
> > NetGetMessage().  This has the potential to drop messages.  Either all of 
> > the code that uses NetGetMessage should be placed into a wait/yeild loop, 
> > or each call should be analyzed to make sure it will behave correctly if 
> > used in a non-blocking manner.  Everything may work okay, but I'm a little 
> > concerned that such a large change in the semantics of the function call 
> > may break other things such as parts of the parallel api code, but this 
> > analysis may have already been done.  
> > 
> > The problem with the wait/yeild loop is that performance will be clobbered 
> > when using OOB.  Maybe having both a blocking and non-blocking version is 
> > the way to go.  Shall we rename the functions to be more precise, ie 
> > NetGetMessageBlock and NetGetMessageNonBlock?  We may need to do the same 
> > for sends as well.
> 
> That's gonna get real messy with the multithreading code. We can't
> just have two functions either, the same situation would occur
> if we ran in a multithreaded build.
> 
> I'd rather work out any issues in the SPU's.
> 
> Feed me with .conf files that show the problems and both Brian and I
> will track the problems down.
> 
> Alan.
>