mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Mann <g...@mesosphere.io>
Subject Re: Review Request 58058: Moved libprocess initialization of worker threads later.
Date Wed, 05 Apr 2017 01:25:24 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message