Re: [g-a-devel]patch to make test-simple work again ...

[Bill Haneman <Bill Haneman Sun COM>]

On Mon, 2002-01-07 at 20:04, Bill Haneman wrote:

Michael wrote:

>	Running out of memory on a system with virtual memory results in a
>fatal trap in glib; there is no security issue with g_strdup.

OK, sure.

>> 
>> !	bonobo_object_release_unref (obj, NULL);
>> !	... = g_list_delete_link (..., obj's element);

>> BH: Seems to me that this can only be a problem in a multi-threaded environment.
>
>	Not at all; when you call bonobo_object_release_unref a CORBA method is
>invoked, at which point _any_ method can re-enter.

...

Certainly if the ORB were MT I see the potential problem here.  It wasn't obvious to me that 
the sync CORBA method (in a single-threaded ORB) could interrupt a server-side operation that 
used the list....  but thinking more about how the ORB handles calls I see the potential 
trouble.    Thanks for the catch.

>> BH: I still maintain that it's better to make
>> BH: the unique id assignment programmatic, in case someday we have
>> multiple
>> BH: copies of this data segment (OK, edge case that is in the future,
>> but still...)
>
>	I've never seen such a thing; for the app to be threaded would be
>amazing, to fork and split into two registryd's seems unthinkable.
>Nevertheless - I've moved the static int increment out into it's own
>method again.

Thanks.  The real issue I was thinking of is the case where not all IDs are assigned by the 
"registryd" registry instance, it's only useful in a couple of the more exotic future 
possibilities involving interoperation with, say, KDE.

...

>> ??? what's with the guards here?  
...
>	The methods are not called; 

Aah, my misreading.  Thanks

-Bill


------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland