[Openais] multiple fd fix for EVT?

Mark Haverkamp markh at osdl.org
Tue Feb 1 07:39:46 PST 2005


On Mon, 2005-01-31 at 17:48 -0700, Steven Dake wrote:
> On Mon, 2005-01-31 at 17:09, Mark Haverkamp wrote:
> > On Mon, 2005-01-31 at 18:36 -0500, Kristen Smith wrote:
> > > Steve/Mark,
> > > 
> > > A while back you had mentioned that you planned on adding 2 fds per
> > > service (one for responses and one for dispatches). Today I ran into a
> > > problem which looks to be caused by 1 fd for the evt service. I was
> > > seeing a race condition where I was trying to do an EvtPublish right
> > > when an EVT message was coming in from another node. I believe what
> > > was happening is that the request/response in Publish was getting the
> > > new EVT message in the response instead of the publish request
> > > response (I hope that makes sense). Basically, since the same fd is
> > > being used by both the publish and the dispatch, it appears that
> > > responses can come in out of order.
> > > 
> > > To get me back up and running, I added a few hacks to lib/evt.c, but I
> > > am sure they are not what is finally intended. So,I was curious if
> > > converting to multiple fds was still on the plate for the evt service
> > > or not.
> > > 
> > 
> > I have my modified evt code still. I would assume that after the totem
> > code is debugged that we'd work on that.  Steve is that the bug 188 on
> > your list of things to do?
> > 
> mark your right about order of working on things.  I think now we are
> pretty safe to work on the evt B while I finish up the recovery handling
> in the base protocols.  We could also work on defect-188.  I'd rather
> get the B services done first (since people are developing code against
> them, modifying and testing that code is easier now then it will be
> later).

I was looking the the evt code yesterday and as it turns out its API is
already mostly at the B spec.  I have to change the size  of a few
things (e.g. handles are now 64 bits), some typedefs are a little
different (e.g. SaAisErrorT), and I need to finish implementation of two
functions (channel open async, and channel unlink).  The open async
function will be easy since I coded the exec function to do the channel
open somewhat async already.  The unlink will take a little bit more
thought, since its specification says that when a channel is unlinked,
any processes with that channel open can continue to use it, but any new
opens of the same channel name will really be talking on a separate
channel.  Right now the channel name is the identifier that I use for
event sending and receiving,   I may have to have some sort of
translation of what the API user specifies and some internal name that I
use for the channel.  I'm not sure yet.

Mark.

-- 
Mark Haverkamp <markh at osdl.org>




More information about the Openais mailing list