Is Conn thread-safe?

[riobard]

From the code I assume it's not. If so, what's the recommended strategy for multiple goroutines to work with a Beanstalk server? Use multiple connections, or share one connection with a lock?

[kr]

Everything in this package is synchronized internally and safe to use
from multiple goroutines without other coordination. I'll add a comment
to the documentation saying so.

[riobard]

Thanks very much @kr !

One question still remains though: sharing a single connection to Beanstalkd is rather hard to deal with due to the blocking nature of reserve. Would you recommend that each worker goroutine establish its own connection to Beanstalkd? Would this impose greater stress on the server?

[kr]

Sharing a single connection should do the right thing with server
semantics even in the presence of reserve (for example, you can
reserve a job in one goroutine, call reserve in another, then delete
the first job; if no new job becomes available, the first job will be
deleted after the server returns DEADLINE_SOON). However, as
you allude, it will block goroutines that are doing operations other
than reserve that are queued behind in-progress reserves.

On the other hand, you can open as many connections as you like.
The server will happily serve tens of thousands of concurrent
connections.

It's up to you.

[riobard]

I see. I think I'll go with one connection per goroutine for better isolation of concerns.

Thanks very much for the explanation!

[mikegleasonjr]

I'm not sure that's right. Sure the connection serializes commands but I think there can be a situation where 2 commands are sent then 2 responses are read.

So I think the lib is co-routine safe but not protocol safe.

Can you confirm?

[kr]

I'm not sure that's right. Sure the connection serializes commands but I think there can be a situation where 2 commands are sent then 2 responses are read.

Sending commands are serialized, and reading responses are serialized in the same order.

So yes, it's possible for two goroutines A and B to send commands A and B, then read responses A and B. The server will send its responses in order and the client will read them in order.

So it is safe to call, for example, Stats and Touch concurrently from two goroutines. Or Reserve and Delete and Peek. Or any other combination of two or more commands.

So I think the lib is co-routine safe but not protocol safe.

Sorry, I'm afraid I don't understand what you mean by this distinction.

[mikegleasonjr]

What about...

coroutine 1 sends command
coroutine 2 sends command
coroutine 2 reads response
coroutine 1 reads response

I just try to wrap my head around text protocol :)

[mikegleasonjr]

Oh I just understood, you are absolutely right it is coroutine safe, I just read this example from text protocol: https://golang.org/pkg/net/textproto/#Pipeline

You are using the same ID to write a request and read a response.

Thanks