Project

General

Profile

Subtask #815

Feature #801: librados: allow access to multiple clusters

Remove globals & partition g_conf

Added by Greg Farnum about 13 years ago. Updated over 12 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
% Done:

100%

Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

This bug is to track the progress of removing globals and setting up g_conf so it can be used as a parameter rather than a global.


Subtasks

Subtask #839: Globals cleanup. Replace g_conf.name with g_conf.entity_name.to_str(). Remove g_conf.type.ResolvedColin McCabe

Subtask #840: Clean separation between different components of initializationResolvedColin McCabe

Subtask #841: don't call daemon_init in library codeResolvedColin McCabe

Subtask #842: initialization: have appropriate library-specific defaultsResolvedColin McCabe

Subtask #843: Decouple dout from g_confResolvedColin McCabe

Subtask #844: g_conf should become a pointerResolvedColin McCabe

Subtask #845: g_conf should not be defined in library code.ResolvedColin McCabe

Subtask #846: De-globalize SimpleMessenger, etc.Resolved

Subtask #1160: introduce CephContext to some structures in common/ResolvedColin McCabe

Subtask #1164: initialize g_ceph_context in common_preinitResolvedColin McCabe

Subtask #1227: write tests of libceph, librgw, librados library thread-safetyRejectedColin McCabe

Subtask #1231: NUM_THREADS=3 testrados segfaultsRejectedColin McCabe

History

#1 Updated by Greg Farnum about 13 years ago

So one issue that occurred to me with setting this up is that we have a number of things that really ought to be globals. For instance, right now the SimpleMessenger can take a single Throttler and use that to restrict the flow of incoming and outgoing messages based on config options in g_conf. While it's good to remove the globals, it's entirely possible that clients will have connections to multiple clusters but still want to have a total limit on how much memory is devoted to caching messages. We'll need some way of implementing that!

#2 Updated by Colin McCabe about 13 years ago

Good point. Some things probably should be global. However, we have a lot of things that library clients don't want to be global as globals now. That's the problem.

Also, even things that should be global, it's not good to have global constructors that do a lot of work. Global constructor time is scary.

#3 Updated by Colin McCabe about 13 years ago

  • Target version changed from 12 to v0.26
  • Estimated time set to 0.00 h

#4 Updated by Sage Weil almost 13 years ago

  • Estimated time set to 0.00 h

#5 Updated by Colin McCabe over 12 years ago

  • Status changed from In Progress to Resolved
  • Estimated time set to 0.00 h

This bug was really all about refactoring stuff to be thread-safe. Now, that task has been completed.

It's time to start testing and fixing any issues that were uncovered. That will be done in bug #1257.

Colin.

Also available in: Atom PDF