Re: so_rerror

[christos%zoulas.com@localhost (Christos Zoulas)]

On Nov 4, 11:25pm, roy%marples.name@localhost (Roy Marples) wrote:
-- Subject: Re: so_rerror

| Yes they will.
| abs emailed me off list about adding a staggered error report for 
| syslogd rather than each time which is another option, but I don't have 
| the time for that right now. But again, it's just another mask on the 
| problem.
| 
| Now that syslogd has the tools to make you happy, can we at least make 
| the default value of the new sysctl (which I note is not the boolean 
| which both Martin and Jason asked for) set to report overflow? Then I 
| think everyone is happy.

Well, I explained why I believed that exposing the mask is better and
limitted the list of allowed settings to the ones that make sense.
As far as the default value goes, the majority of folks who voiced their
opinions asked for it to be off. I personally don't mind it either way
(now that there is a way to control it).

| I *think* you're incorrect.
| Each message sent enters a queue. If this queue overflows, we can't 
| report anything to userland and the kernel will log a diagnostic (afaik 
| no-one has reported this yet).
| For each message which enters the queue it's then processed per socket, 
| then the filtering applies and it enters the receive buffer if it passes.
| 
| Now message queue length is a different beast from buffer sizes granted 
| and the only way I see of optimizing it would be to test if all 
| interested sockets have filters and any filter wants it - if so, it 
| enters the queue, otherwise it doesn't. But as I said earlier, I don't 
| recall any users reporting this diagnostic, I for sure have never seen 
| it and it might be pointless optimisation implementing my suggestion.

Well, I understand how the queueing part works. What I said is that
the filtering happens on the receive side, which does not help the
send side.

christos