More cleanup that needs to be done when an interface isremoved

[Brian J. Murrell]

from the quill of Ted Lemon <mellon at isc.org> on scroll
<200002152105.NAA03183 at grosse.manhattan.fugue.com>
> 
> Hm.   I think the object gets destroyed when the underlying object is
> dereferenced, in omapi_object_dereference.

I thought that's what the code was doing.

> The destroy routine is a
> no-op because there isn't anything to free up in the I/O object.

The destroyed object needs to be removed from the linked list of io objects
though.  That list that is run looking for fds for select I mean.

> I
> don't think the destroy routine is supposed to free the object itself
> - omapi_object_dereference does that.

No.  I suspected as much when I glanced the omapi_object_dereference
routine.  I don't think I am destroying it either... nope.  Here is what I
added to omapi_io_destroy:

+       obj = (omapi_io_object_t *)h;
+
+       /* only ios for interface objects? */
+       if (strcmp(obj -> inner -> type ->name, "interface")==0) {
+       /* remove from the list of I/O states */
+       for (p = omapi_io_states.next; p; p = p -> next) {
+               if (p == obj) {
+                       last -> next = p -> next;
+                       break;
+               }
+               last = p;
+       }

So that the io object is not "select()"ed any more.  I had the
omapi_object_dereference call in there but commented out, just to remind
myself of my uncertainty.

Problem is that I remove that hack to only deal with "interface" objects,
the client... she blows up.  :-)

b.



--
Brian J. Murrell                                    Brian_Murrell at ssd.bctel.net
BCTel Advanced Communications                                      604 454 5279
Vancouver, B.C.