Re: Multi-threading fixes...



Hi Justin,

On Mon, 2003-11-03 at 11:03, Justin Schoeman wrote:
> Anyway, attached is the patch I am using at the moment, which includes:
> 1) Releasing the NameService object after registering the initial 
> service (allows "make check" to succeed if ORBNamingIOR is set).

	This is great; please do commit with appropriate ChangeLog.

> 2) Closes off the race on a connection close.

	So - this is system dependant behavior; I committed the goto msg_error
- which is fine already; we need to lock down the other behavior
properly first.

	It seems to me (from reading the code again) that we have 2 destruction
scenarios:

	* client thread destroy - the ORB thread releases it's
	  CORBA_Object, hence linc-connection ref and we get to
	  link_connection_unref_unlock
		* either we're operating on the object, in which
		  case we hold a ref => no destruction.
		* or we clean up the cnx list and unref it in that
		  thread.
	* I/O thread destroy - the client releases it's reference
	  while we're in link_connection_io_handler, and we release
	  the object at the tail of this.

	So - this all seems fine to me; the stuff is all guarded.

	So - I guess the real question is: what do we do about connections that
we've shut down as a user, and yet during the shutdown we get an
incoming request. My feeling is, we need to keep the connection alive in
these situations.

	So - we could perhaps do this by returning a status from
giop_connection_handle_input something like:

	enum StateChange { START_MESSAGE, END_MESSAGE, NO_CHANGE };

	And inside link-connection's lock grab a ref on cnx for start, release
for end and nothing on no-change.

	Your other mail made it sound like there were a lot of seg-faults as
well - were they assertion failures ? or is there another problem
somewhere ? I suspect that our regression tests are less useful here
since we do synchronous stderr writes in the tests which serializes all
threads unhelpfully - it'd be great to fix that in test/everything.

	Many thanks,

		Michael.

-- 
 michael@ximian.com  <><, Pseudo Engineer, itinerant idiot




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