freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] ipmiconsole_engine_teardown does not seem to block


From: Al Chu
Subject: Re: [Freeipmi-devel] ipmiconsole_engine_teardown does not seem to block as advertised
Date: Thu, 28 Jun 2007 09:32:56 -0700

On Thu, 2007-06-28 at 10:06 -0600, Levi Pearson wrote:
> On Thu, 2007-06-28 at 08:42 -0700, Al Chu wrote:
> > Hey Levi,
> > 
> > Thanks for noticing this.  I'm guessing that the implementation changed
> > awhile back and I forgot to change the comments.
> > 
> > I need to look at the code again the refresh my memory on how best to
> > implement this.  Looking at ipmiconsole (the tool, not the lib) it seems
> > neither ipmiconsole_ctx_destroy() or ipmiconsole_engine_teardown()
> > block.  I actually spin waiting for ipmiconsole_ctx_destroy() to return
> > a non-zero value back to me.
> > 
> > I'll modify the comments for now, and add blocking equivalents into my
> > TODO. 
> > 
> > Is this something that's needed soon on your end?
> > 
> 
> Well, I've got libipmiconsole hooked into the current release of conman
> now, and I'm working on clean up and debugging issues now.  It's worked
> great in my small-scale testing so far, so we'd like to push the
> FreeIPMI tools out into our system image that's being released next
> month.

That's awesome!  How many engine threads do you have running?  How many
nodes?

> Chris sounded like he wanted to do some refactoring of conman before he
> tackled integrating libipmiconsole, but we wanted to see it happen ASAP.
> I'll submit a patch once I'm finished cleaning up, and then Chris can
> use it or not. I won't be offended if it doesn't fit his vision of where
> conman is going, but it ought to at least be a relatively clean solution
> to fitting libipmiconsole into the current conman structure that will be
> useful until he's finished with his refactoring.

> Anyway, part of the cleanup is getting the libipmiconsole stuff cleanly
> torn down when conman closes down via a signal, and the way it's set up
> now, all of the connection objects get destroyed sequentially via a
> list_destroy, and it might be painful to sequentially spin-wait.
> Though, now that I think about it, calling ipmiconsole_engine_teardown()
> before the list_destroy() should ensure that all of them start
> disconnecting at once, so it shouldn't be that bad.

That seem's like a good plan.  Running engine_teardown() then a
list_destroy() on all the contexts.  But, as you state the previous e-
mail, if that's not working, there must be a bug.  I'll take a look.

Al

> 
> I'll see how that works out, so maybe it won't be a time-critical
> enhancement at all.
> 
>               --Levi
-- 
Albert Chu
address@hidden
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory




reply via email to

[Prev in Thread] Current Thread [Next in Thread]