avoid using mutex in hot path (broker/server/store) #29

New Issue

2020-11-05T13:45:20+03:00

vtolstov commented

2020-11-05 13:45:20 +03:00

(Migrated from github.com)

Init() only reinit things if its already connected/started - call Stop()/Start()
Options() alway returns struct and not pointer
Things like store/server/broker not use mutex to get config related stuff

* Init() only reinit things if its already connected/started - call Stop()/Start() * Options() alway returns struct and not pointer * Things like store/server/broker not use mutex to get config related stuff

itzmanish commented

2020-11-08 06:00:08 +03:00

(Migrated from github.com)

Init() only reinit things if its already connected/started - call Stop()/Start()

Are you sure we need start()/stop()?

Options() alway returns struct and not pointer

Any usecase where using pointer instead of struct is useful?

Things like store/server/broker not use mutex to get config related stuff

I don't see mutex used in store/broker/server. Can't say about server and broker but store does need mutex on its write operation.

> Init() only reinit things if its already connected/started - call Stop()/Start() Are you sure we need start()/stop()? > Options() alway returns struct and not pointer Any usecase where using pointer instead of struct is useful? > Things like store/server/broker not use mutex to get config related stuff I don't see mutex used in store/broker/server. Can't say about server and broker but store does need mutex on its write operation.

vtolstov commented

2020-11-08 20:47:38 +03:00

(Migrated from github.com)

Start/Stop is needed because call Init may change listen address or some other major options

As i saw micro does not returned pointer to options struct, so its fine

Mutex is used in server in register func and some other, it needs to protect config options struct, as i saw now this is not needed

Start/Stop is needed because call Init may change listen address or some other major options As i saw micro does not returned pointer to options struct, so its fine Mutex is used in server in register func and some other, it needs to protect config options struct, as i saw now this is not needed

itzmanish commented

2020-11-09 04:35:55 +03:00

(Migrated from github.com)

Init should always be called at very first. After starting server init should not be called. You can't change something in between. Also init is something that doesn't need to call frequently. You call init once and after that you run server.
I personally don't see any required usecase for using start/stop.
If you want then make it optional.

Init should always be called at very first. After starting server init should not be called. You can't change something in between. Also init is something that doesn't need to call frequently. You call init once and after that you run server. I personally don't see any required usecase for using start/stop. If you want then make it optional.

vtolstov commented

2020-11-09 11:08:21 +03:00

(Migrated from github.com)

If you call Init only once and not call it after service started - you don't have any differences. If you call init after start - you don't have any errors and have unexpected behaviour.
Also if you check grpc server implementation in micro/micro it have bug - after first called Init() and before server started - additional invocations of Init() do nothing

If you call Init only once and not call it after service started - you don't have any differences. If you call init after start - you don't have any errors and have unexpected behaviour. Also if you check grpc server implementation in micro/micro it have bug - after first called Init() and before server started - additional invocations of Init() do nothing

itzmanish commented

2020-11-09 15:02:42 +03:00

(Migrated from github.com)

I don't understand why would someone need to call init after service start?

Also if you check grpc server implementation in micro/micro it have bug - after first called Init() and before server started - additional invocations of Init() do nothing

that maybe an error. However usually I don't think I do init after init. If you need then instead of start stop make reinit method and do a stop then init then start inside it.

I don't understand why would someone need to call init after service start? > Also if you check grpc server implementation in micro/micro it have bug - after first called Init() and before server started - additional invocations of Init() do nothing that maybe an error. However usually I don't think I do init after init. If you need then instead of start stop make reinit method and do a stop then init then start inside it.

vtolstov commented

2020-11-09 16:19:35 +03:00

(Migrated from github.com)

internally you call Init multiple times, for example then you specify micro.Registry, micro.Broker , micro.Router and so you internally call server.Init(server.Broker(), server.Registry() .. etc)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unistack-org/micro-roadmap#29