----- On Jun 15, 2017, at 9:02 AM, Denis Yevgenyevich <denis.yevgenyev...@gmail.com> wrote:
> My memory-constrained application dumps core saying > Assertion failed: (!ret), function _cds_wfcq_init, file > ./urcu/static/wfcqueue.h, line 107. > Abort > The function was called from the call_rcu thread, my app does not call > wfcqueue > directly. > My operating system is FreeBSD-10.3, you won't reproduce the failure in Linux. > Apparently developers assumed that pthread_mutex_init cannot fail. This > assumption is ok for Linux, but not so with FreeBSD, which allocates mutexes > with calloc. > Could you please add proper error handling so that (at least) call_rcu threads > could cope with memory allocation failures? > Cheers... Hi, There are interfaces in liburcu such as rcu_read_lock and call_rcu for which we don't want to impose error-handling to users. And in a vast majority of applications, aborting on memory allocation failure appears to be acceptable. So let's see how we could allow special use-cases like yours to be fulfilled without making the API needlessly complex. One possibility would be to add optional handling of out-of-memory scenarios through handlers registered by the application. An application could then use setjmp before calling liburcu functions and longjmp from the registered handler to recover from those errors. Of course, liburcu would have to ensure it's undoing its side-effects before invoking the application-provided out-of-memory handler. Thoughts ? Thanks, Mathieu > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
_______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
