Update docs/readme to note that ocurl client segfaults after fork #68
Description
When Unix.fork is called after setting up the ocurl client, sometimes a segfault happens:
#1 0x0000000002d03758 in __libc_free (p=0x7f264d31b840) at src/malloc/mallocng/free.c:105
#2 0x00000000028e0ab0 in Curl_close ()
#3 0x00000000028c3d24 in curl_easy_cleanup ()
#4 0x00000000028b8752 in removeConnection (connection=0x7f264d4d4940, finalization=finalization@entry=0) at curl-helper.c:691
#5 0x00000000028c11c0 in caml_curl_easy_cleanup (conn=<optimized out>) at curl-helper.c:3283
#6 0x0000000001f46833 in camlCurl__fun_3344 () at curl.ml:1190
#7 0x0000000002cf75ad in caml_start_program ()
#8 0x0000000002ced54d in caml_callback_exn (closure=<optimized out>, arg=<optimized out>) at callback.c:111
#9 0x0000000002cf030e in caml_final_do_calls_exn () at finalise.c:186
#10 0x0000000002cd77b3 in caml_do_pending_actions_exn () at signals.c:280
#11 0x0000000002cdb43a in caml_alloc_small_dispatch (wosize=8, flags=3, nallocs=3,
encoded_alloc_lens=0xa166c53 <camlList___frametable+4179> "\001\001\001") at minor_gc.c:522
#12 0x0000000002cf7476 in caml_call_gc ()
<USER CODE>
This can happen when using parmap after setting up tracing.
It may not be possible to fix this behavior, so it'd be nice if we just noted it down somewhere.
Note that in semgrep/semgrep we were able to fix this by swapping out the otel collector backend for Noop and then calling Backend.cleanup ():
let module Backend = (val backend : Otel.Collector.BACKEND) in
Otel.Collector.set_backend (module Otel.Collector.Noop_backend);
Backend.cleanup ()in the child processes one can then simply call Otel.Collector.set_backend ocurl_backend with a fresh instance of the backend to continue tracing