Another question: we have "lossy", "server", "standy" and "resetcheck" as policy for Messenger, but in practice there exists some overlap semantics among these fields. For example, "server" and "standy" plays the same function in Simple and Async impl. It will let connection standby if losing connection. Maybe we can combine the two? And "lossy" and "resetcheck" also seemed redundancy. If a connection is lossy, we will want to reset the connection state. "resetcheck" is mainly used when server accept a connection and meets conflict, but PR(https://github.com/ceph/ceph/pull/3070) remove this check, so it's really useless in current impl. So could we say that policy for Messenger only have two semantics which are lossy or standy. "lossy" means connection will try to close if aborting. and "standy" will let connection keep state in memory. On Wed, Dec 3, 2014 at 10:21 AM, Haomai Wang <haomaiwang@xxxxxxxxx> wrote: > Thanks! > > On Tue, Dec 2, 2014 at 11:03 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: >> On Tue, Dec 2, 2014 at 12:26 AM, Haomai Wang <haomaiwang@xxxxxxxxx> wrote: >>> Hi Gregoy and Sage, >>> >>> I'm just writing Messenger's unit tests to ensure that SimpleMessenger and >>> AsyncMessenger behavior same and expected. >>> >>> I think the most unclear thing is the lock rule of fast dispatch. When >>> introduced fast dispatch, there exists three methods "ms_fast_connect", >>> "ms_fast_accept", "ms_fast_dispatch" will be called within Messenger's >>> thread. Because without fast dispatcher all messages are delivered from >>> queue to queue, fast path will result in potential dead lock I think. >>> >>> "ms_fast_accept" and "ms_fast_connect" are called with "pipe_lock"(Pipe) or >>> "lock"(AsyncConnection). And Connection::send_message will called outsider. >>> So it may happen: >>> >>> Other thread Messenger's thread >>> lock() connection lock() >>> send_message() connect >>> try connection lock() ms_fast_connect() >>> >>> DEAD LOCK >> >> Sorry, which lock() is the "Other thread" calling? It's not like >> anybody can access the Pipe's lock before it has been connect()ed. >> Or perhaps you're referring to some kind of global lock that you're >> worried ms_fast_connect() will try and access? In that case, yes, the >> rules on locking within the Dispatcher *fast* functions are very >> strict. We basically don't want any of them to take locks at all; in >> the case of the OSD we don't quite manage that and have had to dance >> through a number of hoops to avoid various tight races, but we're very >> close. >> -Greg > > > > -- > Best Regards, > > Wheat -- Best Regards, Wheat -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
