2015-09-02 11:01 GMT+02:00 Shulgin, Oleksandr <oleksandr.shul...@zalando.de> :
> On Tue, Sep 1, 2015 at 7:02 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >> >>> But do we really need the slots mechanism? Would it not be OK to just >>> let the LWLock do the sequencing of concurrent requests? Given that we >>> only going to use one message queue per cluster, there's not much >>> concurrency you can gain by introducing slots I believe. >>> >> >> I afraid of problems on production. When you have a queue related to any >> process, then all problems should be off after end of processes. One >> message queue per cluster needs restart cluster when some pathological >> problems are - and you cannot restart cluster in production week, sometimes >> weeks. The slots are more robust. >> > > Yes, but in your implementation the slots themselves don't have a > queue/buffer. Did you intend to have a message queue per slot? > The message queue cannot be reused, so I expect one slot per caller to be used passing parameters, - message queue will be created/released by demand by caller. > > What sort of pathological problems are you concerned of? The > communicating backends should just detach from the message queue properly > and have some timeout configured to prevent deadlocks. Other than that, I > don't see how having N slots really help the problem: in case of > pathological problems you will just deplete them all sooner or later. > I afraid of unexpected problems :) - any part of signal handling or multiprocess communication is fragile. Slots are simple and simply attached to any process without necessity to alloc/free some memory. Pavel > > -- > Alex > >
