2015-09-02 15:00 GMT+02:00 Shulgin, Oleksandr <oleksandr.shul...@zalando.de> :
> On Wed, Sep 2, 2015 at 2:56 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >> >> >> 2015-09-02 12:36 GMT+02:00 Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de>: >> >>> On Wed, Sep 2, 2015 at 11:16 AM, Pavel Stehule <pavel.steh...@gmail.com> >>> wrote: >>> >>>> >>>> >>>> 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. >>>> >>> >>> I don't believe a message queue cannot really be reused. What would >>> stop us from calling shm_mq_create() on the queue struct again? >>> >> >> you cannot to change recipient later >> > > Well, maybe I'm missing something, but sh_mq_create() will just overwrite > the contents of the struct, so it doesn't care about sender/receiver: only > sh_mq_set_sender/receiver() do. > if you create sh_mq from scratch, then you can reuse structure. Pavel
