RWLock: assert pthread function return values

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
OSD::_share_map_incoming: line wrap debug output

Formatting only.

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
OSD: replace handle_pg_scan, handle_pg_backfill with handle_replica_op

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
DispatchQueue: factor out pre_dispatch and post_dispatch

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
Messenger,DispatchQueue: add ms_fast_dispatch mechanism

This adds a Dispatcher interface allowing the implementation
to accept ms_fast_dispatch calls for some messages without
going through the DispatchQueue.

TODO: before merging, make sure to add comments elucidating
precisely what guarantees you no longer have on
fast_dispatch'd messages.

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
OSDService: add osdmap reservation mechanism

The goal here is to be able to get "reserved" refs
to next_map, and ensure that pgs won't see a newer
map until the ref is "released".  I haven't done
a cute RAII trick here yet...probably not worth
the effort.

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>

Conflicts:
	src/osd/OSD.h
Signed-off-by: Greg Farnum <greg@inktank.com>
OSD: add a RWLock pg_map_lock

If we're going to dispatch ops without grabbing the osd lock, we need
something else to protect the pg map (and it'll be a little
contended, so use a read-write lock).

Signed-off-by: Samuel Just <sam.just@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
OSD: pass osdmap to handle_op and handle_replica_op

We need a map to process them, and we don't want to
take the OSD lock to access one. (And we can't just
use the service because we need all processing of
a message to be done with the same map.)

Signed-off-by: Samuel Just <sam.just@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
OSD::_share_map_incoming: pass osdmap in explicitly

We'll want to be able to use this method without the osd_lock. Note
that we can't do so yet -- we call send_incremental_map, which is not
safe to call unlocked.

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
OSD::send_incremental_map: use service superblock so we can avoid locking osd_lock

TODO: make it actually safe by dealing with build_incremental_map_msg()

Signed-off-by: Samuel Just <sam.just@inktank.com>
OSD: add session waiting_for_map mechanisms

This will replace the existing waiting_for_osdmap mechanism
with a per-session wait list.

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
OSD: remove wake_all_pg_waiters

We shouldn't need this -- we check the pg waiters list on each
map.

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
OSD: wake_pg_waiters atomically with pg_map update

Also, call enqueue_op directly rather than going back
through the entire dispatch machinery.

Signed-off-by: Samuel Just <sam.just@inktank.com>

Conflicts:
	src/osd/OSD.cc
	src/osd/OSD.h
Signed-off-by: Greg Farnum <greg@inktank.com>
OSD: add dispatch_op_fast and supporting mechanisms

This patch adds a fast path for osd ops which bypasses
the osd_lock and should not block on any longly held
locks.

Signed-off-by: Samuel Just <sam.just@inktank.com>

Conflicts:
	src/osd/OSD.cc
	src/osd/OSD.h
Added the EC operations to the fast_dispatch path and fixed the conflicts.
Signed-off-by: Greg Farnum <greg@inktank.com>
Pipe: handle accept and connect syncronously

Signed-off-by: Samuel Just <sam.just@inktank.com>
OSD: fill in Session in ms_handle_connect

Signed-off-by: Samuel Just <sam.just@inktank.com>
OSD: set up Session in ms_handle_accept

Signed-off-by: Samuel Just <sam.just@inktank.com>
Revert "Pipe: handle accept and connect syncronously"

This reverts commit 3267b54425a641cd628559d2944061980e058940.
We shouldn't do synchronous notification of Sessions: the Dispatchers
tend to take big global locks inside of these functions, and we could
delay starting the reader() thread or acking the connection as a result.
In regards to the only ms_fast_dispatch() user, the OSD doesn't implement
ms_handle_accept(), only cares about ms_handle_connect() for monitors, and
creates its Session objects in ms_verify_authorizer() anyway, so the possibility
of receiving a Message out of band with receiving the notification about its
new Connection is just fine.

Signed-off-by: Greg Farnum <greg@inktank.com>
Revert "OSD: fill in Session in ms_handle_connect"

This reverts commit ab19a5203163a0ec4fa0c394e1338ee88476e835.
It's simply not needed; the ms_verify_authorizer() call fills in Sessions
and is called much earlier.

Signed-off-by: Greg Farnum <greg@inktank.com>
Revert "OSD: set up Session in ms_handle_accept"

This reverts commit 963d4c770777ec58351c2fd191ff283ddbadebea.
It's simply not needed; the ms_verify_authorizer() call fills in Sessions
and is called much earlier.

Signed-off-by: Greg Farnum <greg@inktank.com>