[Vortex] How to correctly close a connection?

Robert M. Münch robert.muench at robertmuench.de
Mon Oct 6 20:08:25 CEST 2008

Am 06.10.2008, 18:52 Uhr, schrieb Francis Brosnan Blazquez  
<francis at aspl.es>:

> If so, you can use vortex_channel_is_ready to check every channel on the
> connection (with capabilities to transfer). If all of them are ready (no
> pending message to be replied) you can safely use
> vortex_connection_close without blocking.

Hi, ok I see. So this is the way to check if a connection is currently not  
transferring any messages?

> Of course this assumes the listener won't bother with new messages
> during the call to vortex_connection_close.

Yes, that's clear. I'm thinking about a handshake way by annoucing a  
connection-close from client to server, wait for ACK from server and than  
close the connection.

>> Ok. The client uses a shutdown call for this. On the receiver side, I
>> do it by hand because the receiver switches back to listening state to
>> serve other possible client connections.
> What you mean "by hand"? In any case, if the client side is controlling
> connection close, do nothing at the listener.

"By hand" I mean doing some housekeeping things like tracking of logged in  
users etc. So nothing vortex related.

>> #0  0xb7ebc71c in free () from /lib/tls/i686/cmov/libc.so.6
>> #1  0xb7d3060d in axl_hash_free (hash=0x3e8bb) at axl_hash.c:1216
>> #2  0xb7d028f8 in vortex_hash_destroy (hash_table=0x821a908)
>>      at vortex_hash.c:357
>> #3  0xb7cebdf1 in vortex_connection_free (connection=0x821a598)
>>      at vortex_connection.c:2494
>> #4  0xb7d00d61 in __vortex_reader_build_set_to_watch_aux (
>>      on_reading=0x814f118, cursor=0x814f840, current_max=10)
>>      at vortex_reader.c:971
>> #5  0xb7d0200d in __vortex_reader_run (ctx=0x814e108) at
>> vortex_reader.c:1228
>> #6  0xb7cc5240 in start_thread ()
>> from /lib/tls/i686/cmov/libpthread.so.0
>> #7  0xb7f2249e in clone () from /lib/tls/i686/cmov/libc.so.6
>> Any idea?
> It really looks like the connection is being closed or deallocated
> twice.

Hmm... The only one closing a connection is the client. The server only  
executes the on_connection_closed handler, which prints a message. The  
crash happens after the on_connection_closed handler returns. I can  
comment the handler and get the same effect.

> Do you call to close or unref or shutdown at the listener side
> when the client side closes?

No, nothing is called. So, this is really strange because on the server  
side there is nothing fancy happening. The server calls:


inside the on_connection_closed handler. But I don't expect these to have  
any sideeffects. Any idea how I can track it further down?

Robert M. Münch
Mobile: +49 (177) 245 2802

More information about the Vortex mailing list