Hi Felix, I understand. I just sent an alternative patch which maintains an independent linked list which I think should circumvent the corruption of the same. This of course introduces some additional memory allocation on the heap.
When this shouldn't be an option, what would be your suggestion to deal with the problem of a higher number of objects and then trying to list them? Maybe we could also wait until the written data to the socket is flushed for each found object in that case? Benjamin On Thu, 2018-05-03 at 11:07 +0200, Felix Fietkau wrote: > Hi Benjamin, > > On 2018-05-02 22:55, Benjamin Hansmann wrote: > > The fixed size array for queuing messages led to discarding > > messages > > when it was full, using a linked list instead solves this issue. > > > > Having the list_head link in the ubus_msg_buf itself avoids the > > allocation of more memory for an independent list. > > > > The motivation was that for a recursive "ubus list" the function > > ubusd_proto.c:ubusd_handle_lookup() produces more than n messages > > in > > one uloop cycle when n objects are registered on the bus. > > > > Signed-off-by: Benjamin Hansmann <i@qbox.audio> > > The reason for using an array is that a message can be queued for > multiple clients. Doing that with your patch could corrupt the list > in > that case. > > - Felix > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
