I'm not sure this is exactly the issue. Having a single call to get
expected or unexpected or both is a good idea, but the issue here seems
to be the call waiting until the desired context has completed ops
versus returning short because there are operations from other contexts
(or unexpecteds
On Jan 6, 2009, at 9:40 PM, Rob Ross wrote:
the fact that zoidfs is blocking is irrelevant to how the server
implements servicing the calls. -- rob
The server implements servicing the calls by calling zoidfs functions,
which in turn call PVFS..
-sam
On Jan 6, 2009, at 9:15 PM, Sam L
the fact that zoidfs is blocking is irrelevant to how the server
implements servicing the calls. -- rob
On Jan 6, 2009, at 9:15 PM, Sam Lang wrote:
On Jan 6, 2009, at 7:51 PM, Rob Ross wrote:
Hi Sam,
My take on your email was that you were combining the two issues,
so I wanted to make
On Jan 6, 2009, at 7:51 PM, Rob Ross wrote:
Hi Sam,
My take on your email was that you were combining the two issues, so
I wanted to make sure that we were in agreement that the alternative
API was preferred (not that I think we should necessarily do
anything about it at the moment). I'
Hi Sam,
My take on your email was that you were combining the two issues, so I
wanted to make sure that we were in agreement that the alternative API
was preferred (not that I think we should necessarily do anything
about it at the moment). I'm glad we are in agreement.
The terms "schedul
On Jan 6, 2009, at 5:03 PM, Rob Ross wrote:
I think if we had this alternative design and one wanted to have
different priorities, one would look for messages under different
contexts as you say. But when you don't care about priority, it
would be nice to be able to get everything in one c
I think if we had this alternative design and one wanted to have
different priorities, one would look for messages under different
contexts as you say. But when you don't care about priority, it would
be nice to be able to get everything in one call.
Rob
On Jan 6, 2009, at 4:57 PM, Sam Lan
Changing the API as you describe would actually bring back the
original problem. As is, the BMI_tcp_testcontext call knows that
there are unexpected messages waiting, so it returns immediately
(expecting a call to testunexpected to follow). This is a specific
policy hard-coded in the tc
Yeah a special named context for unexpected message would be a clean
way to have done things... -- Rob
On Jan 6, 2009, at 2:49 PM, Phil Carns wrote:
Yeah, I don't particularly like adding special cases either.
I feel like making the consumer play with timeouts or use an extra
thread would
Yeah, I don't particularly like adding special cases either.
I feel like making the consumer play with timeouts or use an extra
thread would be just as much of a hack/workaround, though. Its just
moving the problem elsewhere.
Fundamentally it seems more like a BMI API flaw. It would have ma
I've committed the set_info fix for this. I'm not crazy about it, but
it should work for now. In the long term, we should probably move
away from method specific hacks like this. I.e. it should be up to
the API consumer (our server) to adjust timeouts or call
testunexpected in a separa
11 matches
Mail list logo
