Re: More multi-threading questions...

[Justin Schoeman <justin expertron co za>]

*AAARRGGGHHH*

...

Oh well, it didn't help. Still the same two assertions, even although I 
am using only one global ORB, and am using the glib main loop. The glib 
main loop terminates correctly, then the server code tries to call a 
CORBA client method (to unbind from the name service), and bang:

** ERROR **: Failed to write to GIOP wakeup socket -1 0x9(9) (-1)

 From the backtrace, it seems as though this occurs because the main 
loop has exited? How do I get around this? Should I run the main loop in 
a separate thread, and only kill it off after all client operations have 
completed?  This is getting horribly complicated, there _must_ be an 
easier way...

Still no idea how the occasional:

** ERROR **: file giop-connection.c: line 69 (giop_connection_dispose): 
assertion failed: (cnx->incoming_msg == NULL)

occurs -> I have not been able to duplicate it in gdb yet...

Michael Meeks wrote:
> Hi Justin,
> 
> On Tue, 2003-09-09 at 08:39, Justin Schoeman wrote:
> 
>>Sorry, my mistake, I meant the server main loop.  At the moment I exit 
>>the main loop by calling CORBA_ORB_shutdown from a signal handler. 
> 
> 
> 	Ah ! - in which case yes; just run the glib mainloop instead of your
> custom one so:
> 
> 	CORBA_ORB_init ();
> 
> 	loop = g_main_loop_new(g_main_context_default(), TRUE);
> 	g_main_loop_run (loop);
> 
> 	CORBA_ORB_destroy ();
> 
> <signal handler>
> 	g_main_loop_quit (loop);
> 
> 
>>Unfortunately, this means that I can no longer use the CORBA client to 
>>unregister from the name service (unless I re-initialise CORBA, which I 
>>suppose is an option).  Is there another way to terminate the CORBA 
>>server main loop (without terminating the ORB).
> 
> 
> 	As above; we hook into the default glib main context.
> 
> 
>>This is for a 'universal' vending platform.  Some stock types can take a 
>>while for purchases to complete, so the purchases need to take place in 
>>separate threads...
> 
> 
> 	Sounds interesting.
> 
> 
>>PS: Bonus marks to anybody who can find the memory leak in the test app! 
>>  It seems to leak about 4 bytes for every object instantiate/destroy 
>>cycle (in single or multi-threaded mode).
> 
> 
> 	Really ? that's pretty bad; prolly your servant I'd guess. 

Nope, I don't think so - this all pretty much follows example code from 
the web, and the memory being leaked is less than any of my allocations!

TIA,
-justin