From: Alan H. <al...@re...> - 2002-06-28 11:15:42
|
Ah, Now it makes sense what your seeing. I didn't realize that NetGetMessage is actually used in the binaryswapspu. I thought it was only used in crserver. I'm looking into it now. Alan. On Fri, Jun 28, 2002 at 11:28:21AM +0100, 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. > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Caffeinated soap. No kidding. > http://thinkgeek.com/sf > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev |