Does sync.Pool hold multiple items or just one? And if it holds more than one then how to do it?

[brittle tide]

Does sync.Pool hold multiple items or just one? And if it holds more than one then how to do it?

[astral island]

sync: Pool

type Pool struct {

A Pool is a set of temporary objects that may be individually saved and retrieved....

More documentation omitted

[plucky anvil]

From the docs:

A Pool is a set of temporary objects that may be individually saved and retrieved.

Emphasis on objects

[shut jungle]

The idea behind sync pool is to reuse allocated objects

You give it a new function, get a pool

from that pool you can get and put objects

[brittle tide]

Right, so let's say if I want to hold multiple connections to one grpc server, is it applicable to use it to save 3 connections for example?

[shut jungle]

pools can store dirty or new objects

It is applicable, but maybe not the most appropriate

I would recommend doing the pooling lower, at the net.Conn level

well, I'm not sure exactly how the grpc connections looks like, but not having to deal with the pool in API land is better

[brittle tide]

Have you worked with gRPC previously?

[shut jungle]

If you have a fixed number of connections, you might not just need a pool at all

[brittle tide]

But goroutines will be accessing these connections

[shut jungle]

if you feel like that's a nice enough api, go ahead, I haven't used grpc so I'm not really sure the implications on conn lifetimes etc

[brittle tide]

Yeah, connections persist throughout the life of the application basically

But have you used sync.Pool till now? and if so where was it applicable?

[shut jungle]

I've used it to reuse memory buffers

pretty sure the net/http stack uses it for requests too

[slim pumice]

sync.pool is not storage, item in it may get GC'ed at anytime. its not for something with long livetime, its for something that you create and destroy often (to avoid burst allocation), since it does not guarantee object liveness.
~
second, i belive GRPC already do that for you, connection pooling.

[brittle tide]

I am not sure if gRPC does that, if you want to create a connection, you have to create it and it gets garbage collected if you dont cache it

[slim pumice]

wrong link

[slim pumice]

you're right. the doc (or source code) does not mention anything about pooling.
though, grpc client is safe for cuncurent use, i assume, high concurency on single client may cause congestion.

[brittle tide]

func (client PhysicistsInfoClient) GetPhysicistsById(id string) *pb.Physicist {
    conn := PhysicistsInfoConnections.Get().(grpc.ClientConnInterface)
    defer PhysicistsInfoConnections.Put(conn)
    c := pb.NewPhysicistsInfoClient(conn)
    byId, err := c.GetPhysicistById(context.Background(), wrapperspb.String(id))
    if err != nil {
        log.Println("Error")
    }
    return byId
}

I call use go before GetPhysicistById every time a request is sent

So I am creating a client for each request but using pool for the connection, so the clients will be sharing the connections

[slim pumice]

does one client for multiple request enough? did you feel the congestion?

[brittle tide]

Well..No..There is a one client for one request

So if we say there are 10 requests, there will be 10 clients sharing or trying to access 3 connections from pool

[slim pumice]

if you use pool, there is no sharing. 10 requests, 10 client created and maybe will be reused for the next 10 requests.

[brittle tide]

What..? In order to create a client I need a connection..

And connections are only available in the pool

[slim pumice]

oh ya, i missed the .(grpc.ClientConnInterface) part. so 10 connection will be created.

arent the generated code, give you client factory, something like tokenconnect.NewTokenManagerServiceHandler?

hm.... arent the client from the factory manage the connection?