bug in nl_cache_mngr_data_ready / nl_cache_refill / nl_cache_resync [+patch proposition]
brett.ciphery at windriver.com
Mon Apr 23 10:42:58 EDT 2012
[Re: bug in nl_cache_mngr_data_ready / nl_cache_refill / nl_cache_resync [+patch proposition]] On 21/04/2012 (Sat 06:51) Thomas Graf wrote:
> On Thu, Apr 19, 2012 at 01:09:10PM -0400, Thomas Graf wrote:
> > What we can do is extend recvmsgs() do offer both behaviours
> > and have the cache manager direct it to continue reading
> > as long as there is data.
> > I'll fix that. I'm planning to look into and improve the
> > cache manager anyway. It's not reliable enough at the moment.
> See commit a518a31 (cache_mngr: Let nl_cache_mngr_data_ready()
> read multiple messages).
> It should fix your case Brett while keeping the behaviour for
> blocking sockets the same.
I was looking at comments of nl_recvmsgs() which
* Repeatedly calls nl_recv() or the respective replacement if provided
* by the application (see nl_cb_overwrite_recv()) and parses the
* received data as netlink messages. Stops reading if one of the
* callbacks returns NL_STOP or nl_recv returns either 0 or a negative
* error code.
and so thought the expected behaviour would be to loop until there was
nothing left. Returning a count is clean though, I'll check how this
works with nl_cache_mngr_data_ready() and other cache refilling
More information about the libnl