Paul Jackson wrote:
> Andi wrote:
>> numa_error("request to allocate mask for invalid number; abort\n");
>> - return NULL;
>> + exit(1);
>
>
> My usual rule of thumb is that system libraries should not be printing
> errors, and should not be exiting.
It used to be this way, but all the callers don't check for NULL currently
and they would crash a few instructions later. So it's better to exit() for this. Besides running
out of memory is usually fatal anyways and impossible to handle.
One would not want a major user
> level service process that happened to be linked with libnuma, deep
> down in some corner, just going "poof".
The libnuma error concept is that by default it prints output and doesn't
exit (because numa is just an optimization), unless numa_exit_on_* is set.
Also the functions that do this are weak so if you want special
error handling the application can override this (e.g. a C++ app could
raise an exception instead or do something else)
> System libraries simply must not have unintended side affects ... such
> as exits or unrequested file (stdout or stderr) output.
Actually stderr output is pretty common and fine.
In some narrow
> example, for a particular use, such side affects might seem to make
> sense, but once a major user space system service is up and running,
> linked perhaps with several dozen such libraries that no one human even
> knows about entirely, such side affects lead to unexpected behaviour.
>
> The WEAK numa_error symbol provides a way out of the unintended output
> problem, but it has the wrong default -- output unless the application
> takes special actions to suppress that output.
I think some default warnings on output are fine. Otherwise you risk your
NUMA optimizations silently breaking and someone needing to take a lot
of effort to track down the performance issues.
Besides there are lots of other libraries that print by default too
and it's actually ok for many use cases (like GUI apps)
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-numa" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
