> 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 :( > > Greg Mann wrote: > 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?
Regarding `evconnlistener_new`, as long as the destructors for all SSL sockets have executed, then all of their listeners should have been freed? And with your synchronous socket destruction change, we could be assured of that. - 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 > >
