Hi Levi,

> However, the ipmiconsole_engine_submit, which doesn't block, also 
> doesn't set the flag to notify when the connection is established.  I
> can't see any mechanism in /usr/local/include/ipmiconsole.h that would
> allow me to determine when a non-blocking submit is ready to use.  Am I
> missing something?

At the moment there isn't anything to let you know when the session has
finished being setup using a non-blocking submission.  The belief was
that a user would get the file descriptor immediately after submitting
the context, and if the file descriptor was closed by the other end,
that would inform the user that an error occurred, otherwise things were
happy.  So I imagined something like this (which was what was done in
ipmiconsole prior to 0.3.2):

ipmiconsole_engine_init();
c = ipmiconsole_ctx_create();
ipmiconsole_engine_submit(c);
fd = ipmiconsole_ctx_fd(c);
while (1)
{
  /* do select() on fd */
  if (FD_ISSET(fd))
  { 
    n = read(fd);
    if (n)
      /* do something with the data */
    else
      printf("error: %s\n", ipmiconsole_ctx_strerror(...));
  }
}

In hindsight, you make a good point that some may want to be notified
that a non-blocking context has finished making its connection vs.
receiving an error.  I'm not sure of the best method though.

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.

Option #2) Have a special flag/something on the file descriptor returned
to the user indicating the connection is complete.
   - Pro: Easy
   - Con: Messes up semantics of what the prior file descriptor means

Option #3) Create another pipe that can return separate special status
flags to the user
   - Pro: Keeps semantics of all earlier code
   - Con: more fds, ugh ..

Is having a non-blocking completion/notification mechanism something you
think will be necessary?  I'll ping Chris Dunlap about Conman's needs
too.  The original idea was based solely on Conman's needs, and this may
have been a "hole" in the design we had forgotten to consider.

Al

On Tue, 2007-05-29 at 12:45 -0600, Levi Pearson wrote: 
> I'm playing around with libipmiconsole to figure out how to use it to
> access multiple consoles at once.  Looking at the exported API and the
> implementation, I'm curious how non-blocking context submissions are
> supposed to be handled.  
> 
> The ipmiconsole_engine_submit_block implementation adds a flag to the
> ctx struct before submitting it telling the engine to write a piece of
> data to the pipe as soon as it's established and then uses its own
> select call to block until something is written to the pipe.
> 
> However, the ipmiconsole_engine_submit, which doesn't block, also
> doesn't set the flag to notify when the connection is established.  I
> can't see any mechanism in /usr/local/include/ipmiconsole.h that would
> allow me to determine when a non-blocking submit is ready to use.  Am I
> missing something?
> 
>               --Levi
> 
> 
> 
> _______________________________________________
> Freeipmi-devel mailing list
> Freeipmi-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/freeipmi-devel
> 
-- 
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


_______________________________________________
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Reply via email to