From: Mike H. <mho...@gr...> - 2002-06-28 17:19:27
|
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. > |