> On April 4, 2017, 9:58 p.m., Greg Mann wrote: > > IIUC, previously-queued events can execute in a later instance of > > libprocess because they persist in the file-scope `functions` queue that we > > declare in the event loop implementations? So this patch still allows > > previously-queued events to execute, but ensures that any GC-managed > > processes they spawn will be GC'd correctly? > > > > If so, perhaps we could clear the `functions` queue during > > `EventLoop::stop()` instead, to ensure that no previously-queued events are > > executed at all. WDYT? > > Joseph Wu wrote: > Unfortunately, the `functions` object we keep in the thread's memory does > not actually include all the callbacks. It basically only includes functions > we add via `run_in_event_loop`. Other libevent-APIs will end up putting > lambdas in libevent's own storage (such as, for server sockets, > `evconnlistener_new`). > > So clearing `functions` doesn't help for the segfaults in this chain :(
True, but once we call `EventLoop::stop()`, libev/libevent will no longer queue up new callbacks on the event loop, right? So if, during finalization, we clear the `functions` queue and wait for all pending event loop callbacks to execute (which should be the case by the time the event loop thread joins), then I think we could be assured a clean finalization with no pending callbacks that would execute when libprocess is initialized again? - Greg ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58058/#review171046 ----------------------------------------------------------- On March 30, 2017, 1:20 a.m., Joseph Wu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/58058/ > ----------------------------------------------------------- > > (Updated March 30, 2017, 1:20 a.m.) > > > Review request for mesos, Benjamin Mahler and Greg Mann. > > > Bugs: MESOS-6919 > https://issues.apache.org/jira/browse/MESOS-6919 > > > Repository: mesos > > > Description > ------- > > This commit moves the creation of all libprocess worker threads > after the creation of the garbage collector process. > > This deals with a test-only case where: > 1) Events are queued on the event loop. > 2) Libprocess is finalized as part of the test, > before processing all events. > 3) Libprocess is reinitialized and the previously queued events > are allowed to resume. > > Because the events were queued in a previous incarnation of > libprocess, they potentially bypass the synchronization variables > in `process::initialize` (i.e. `initialize_complete`) and can > spawn garbage-collected processes before the garbage collector > has been spawned. > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > f6ee24e2db43d63d91222549efee85421bbf9bf3 > > > Diff: https://reviews.apache.org/r/58058/diff/1/ > > > Testing > ------- > > See end of chain > > > Thanks, > > Joseph Wu > >
