Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make each client thread safe #35

Closed
wants to merge 9 commits into from

Conversation

harlowja
Copy link
Contributor

  • Add a object pool that can create sockets in a thread
    safe manner (and release and destroy them as/when needed).
  • Avoid using a client 'buffer' and use a per-function/method
    buffer instead to avoid having multiple threads writing into
    the same buffer.

Fixes issue #34

Joshua Harlow added 9 commits April 13, 2015 18:33
@cgordon
Copy link
Collaborator

cgordon commented Apr 14, 2015

Hey Josh, thanks for the pull request! I've been meaning to add connection pooling (and consistent hashing) to pymemcache, but time is always in short supply (and we use an external proxy for that at Pinterest, so we haven't needed it).

One of the design goals of the Client object was that it be easy to compose so we could add things like pooling and hashing later, without having to change it. For instance, my preference for pooling would be to create a separate PooledClient that maintains a pool of Client objects and implements each method like this:

def add(self, key, value, expire=0, noreply=True):
    with self.client_pool.get_and_release() as client:
        return client.add(key, value, expire=expire, noreply=noreply)

This means that users of Client don't have to pay any extra overhead for pooling (however small), but anyone who wants can use pooling with the same interface (it's a drop-in replacement) with only a small extra overhead (one extra method call). In the future, if we also add a HashingClient (or something similar) we could have PooledClient keep a pool of those, and have the HashingClients delegate to Clients, keeping everything nicely orthogonal. What do you think? Is there something about this particular change that precludes that approach?

Separately, converting buf to a local variable looks both safe and more straightforward than having it as an instance variable. I cannot remember, now, why I wrote it as an instance variable originally, but it's probably vestigial. If you want to make that change, it would be great, or I can do it after this PR.

CG.

@harlowja
Copy link
Contributor Author

That seems fair, I should be able to reuse this little object pool thingy for that.

@harlowja
Copy link
Contributor Author

Will attack that way of doing it tommorow :-P

@harlowja
Copy link
Contributor Author

Reworking, will open new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants