mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Wu <jos...@mesosphere.io>
Subject Re: Review Request 58058: Moved libprocess initialization of worker threads later.
Date Wed, 05 Apr 2017 00:04:14 GMT


> On April 4, 2017, 2: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?

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


- Joseph


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58058/#review171046
-----------------------------------------------------------


On March 29, 2017, 6:20 p.m., Joseph Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58058/
> -----------------------------------------------------------
> 
> (Updated March 29, 2017, 6:20 p.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