On Tue, 2007-05-29 at 15:26 -0700, Anand Babu Periasamy wrote:
> Al Chu writes:
> > Hey Levi,
> > 
> > Thinking about this just a tad more, 
> > 
> >> Option #1) Create a function that returns some notification status to
> >> the user.
> >>    - Pro: Easy
> >>    - Con: No select/poll mechanism for anyone creating a lot of
> >> contexts.
> > 
> > I think this would be fine in the end after all.  The non-blocking case
> > that (I imagine) we're truly concerned about is that a user may try to
> > write data to the console before the SOL connection is finished
> > establishment.  A simple flag check prior to the write will allow us to
> > reject that write if we so choose.
> > 
> > Sound like a good way to fix this problem?
> > 
> > Al
> You have given the option of both blocking and non-blocking engine_submit 
> anyways. There won't be any reason to use non-blocking call and wait
> till initialization completes. 

If you want to establish 1000 SOL connections, you do not want to block.
You want to "launch" all the SOL connection attempts simultaneously and
(at the end) wait for the remaining few to finish.

> Callback interface will allow the user
> to handle notifications instantly, but it is not that useful in this
> case because of its complexity. Flags are easier way to handle
> it. Let us have a flag in the user submitted context and the engine
> will lock/set-flag/unlock when the session initializes properly
> You may have to introduce one more call to check if the context is
> ready for I/O. It is just a wrapper call to check the flag. 

That was my feeling, just a function that checks an internal flag and
returns yes or no to the SOL connection being established.


Albert Chu
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

Freeipmi-devel mailing list

Reply via email to