Re: so_rerror

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

On Nov 7, 12:10pm, roy%marples.name@localhost (Roy Marples) wrote:
-- Subject: Re: so_rerror

| It's clear that you don't care about auditability or traceability.
| If I have any things running, which one was it discarded for and why?

He does, but the applications don't and they are not in a position to
do anything most of the time (and don't care).

| > The pushback is against informing applications which cannot rationally
| > do anything about it .in general ... there is no way to prevent an
| > occasional overflow when ciccumstances conspire to make a very
| > large number of messages all arrive at once - all making the buffer
| > bigger does is to allow more of all of that to be queued (removing the
| > logging from the time of event more than it should be) and meaning that
| > an even bigger buffer perhaps gets allocated, to handle once in a
| > century type events.
| 
| There isn't much I can do about an ENOSYS error either.
| Maybe we should silently discard those too?

This is why SIGSYS comes with it, because the process is going to be killed
unless you arrange for it to handle it. (I.e. the default action is sane; it
is one thing for an application to expect a system call to be there and fail
and another it missing alltogether)

| You know what?
| I no longer care.
| I no longer care that I spent months figuring out a long standing issue 
| around stuff that packets were being lost in a self contained system 
| because the important error WAS NOT BEING REPORTED.
| 
| I no longer care to inform the admin that their logging server just 
| can't keep up with demand and pretend that life is dandy.
| 
| Feel free to rip my code out and put back all the comments saying XXX 
| report this to userland.
| I'm done with this shit that wants to make a developers life harder and 
| not easier.

Well, the code is still there as we all agree it is useful for the
routing socket. It is just not very useful for other applications.
Some people care about seeing in their /var/log/messages 'syslog:
out of buffer space', others know that this happens occasionally
and it is just noise to them. Now they can choose what behavior
suits them.

We can even consider making it default to on in the future, once we
determined it is not harmful.

What concerns me is that the unit test t_sendrecv behaves differently
in the presence and absense of SO_RERROR and it should not.

christos