Commit Graph

13 Commits

Author SHA1 Message Date
Lee Howes
092484e255 Future<T>::then 4/n: Future<T>::then(not-try-task) -> Future<T>::thenValue(task) xplat.
Summary:
Overall plan to modify Future<T>::then to be r-value qualified and use Future<T>::thenTry or Future<T>::thenValue.

The goal is to disambiguate folly::Future and to improve type and lifetime safety of Future and its methods.

4/n: Codemod:
 * rvalue-future<T>.then(callable with operator()(not-a-try)) to rvalue-future<T>.thenValue(callable with operator()(not-a-try)).
 * rvalue-future<T>.then(callable with operator()()) to rvalue-future<T>.thenValue(callable with operator()(auto&&)).
 * rvalue-future<T>.then(callable with operator()(auto)) to rvalue-future<T>.thenValue(callable with operator()(auto)).

 Applied to xplat.

Reviewed By: marshallcline

Differential Revision: D9133114

fbshipit-source-id: 30cc4f0480ca04b3abda54af3aafd9fc4dfdf0e0
2018-08-03 03:21:41 -07:00
John Knox
d0ecb46d64 Skip initialisation if not running in own thread
Summary:
One design goal of sonar is to never cause the host app to crash or hang.
For this reason, we do all heavy work in a background thread.
If we detect that it's not running in it's own thread, just return so we don't hold up the caller.

Reviewed By: danielbuechele

Differential Revision: D8767288

fbshipit-source-id: e146cc2cfe5c3e62d12f527ff79f24c74873d4ff
2018-07-09 07:49:09 -07:00
John Knox
85e6bf6d51 Stop using delayedUnsafe
Summary:
Having another attempt at removing this. It's unsafe because it in some cases executes the .then() task in the timekeeper thread, rather than the executor the original future is using.
When that default executor is an InlineExecutor, for example, you can get stack overflow.

I tried to remove this use before, but having the same thread used for both the sonar client itself and rsocket, meant that they entered a deadlock trying to connect.
Now that I've separated those jobs into separate threads, they can execute independently.

Reviewed By: danielbuechele

Differential Revision: D8748356

fbshipit-source-id: a1029ece2c7006ad7642cbf8aa59e692c76b19b2
2018-07-09 07:49:08 -07:00
John Knox
cebc409da6 Change SonarInitConfig to take two EventBases
Summary:
We currently give sonar one event base from java / obj-c code to use for scheduling tasks.
This causes a problem, because we schedule reconnect tasks on the event base, and then these tasks interact with rsocket which schedules it's own tasks.
The problem is that we're passing rsocket the same event base. So the reconnect code executes and blocks waiting for rsocket to connect.
But rsocket can never connect because it never executes because that thread is blocked, so we get deadlock.

This is the first step which just changes the interface to pass two event bases.
The consumers will be changed to pass in different threads next.

Reviewed By: danielbuechele

Differential Revision: D8748350

fbshipit-source-id: 481d6f23644f28fd0f1c786252605287019c999c
2018-07-09 07:49:07 -07:00
John Knox
f8c79b55dc Back out "[sonar] Stop using folly Future::delayedUnsafe()"
Summary: Original commit changeset: 51ab3224b93e

Reviewed By: priteshrnandgaonkar

Differential Revision: D8676855

fbshipit-source-id: 38282f642d8497ce7715017127368445132454fa
2018-06-28 04:32:32 -07:00
John Knox
70e11e8269 Stop using folly Future::delayedUnsafe()
Summary:
delayedUnsafe() is unsafe because it disregards the executor you have specified, and uses the default one.
Depending on the context, this can sometimes be an InlineExecutor, and since some of the scheduled jobs, schedule instances of themselves, this can cause infinite recursion to occur.
Fixing this by using the safe variant of delayed, and also using a new instance of IOExecutor.
We need a new Executor for the Sonar loop, because if we use the same worker thread as is provided to RSocket, we get deadlock when we wait for rsocket to connect.

Reviewed By: danielbuechele

Differential Revision: D8617679

fbshipit-source-id: 51ab3224b93e774596a8799338e7391e2eb956cb
2018-06-25 16:03:18 -07:00
Daniel Buchele
6fda334a00 fbshipit-source-id: 5d9ecf33fca19e4a6b8c979b879ec9dd82af1ef9 2018-06-25 04:33:04 -07:00
John Knox
992c032fe7 Fix infinite recursion issue when can't connect
Summary:
There's an issue with folly's delayedUnsafe(), where it drops your executor and effectively
runs all futures inline, in this case instead of scheduling tasks for the future, it grows the stack indefinitely.

This fixes the issue by using the safe delayed(), which preserves the executor, so the jobs get shceduled on a different thread as intended.

Reviewed By: LeeHowes

Differential Revision: D8575956

fbshipit-source-id: c5b2ced43a70505c51883281f202ac947ae6723f
2018-06-21 13:18:25 -07:00
Daniel Buchele
6f95ad512f fbshipit-source-id: b14273e883aba6de7b817801a1b04e54a29a6366 2018-06-15 02:23:48 -07:00
John Knox
4fbe638adf Silence expected error logs
Summary:
When an app with sonar is run for the first time, the necessary files don't exist.
This is expected, so don't output an error, only error if they do exist but there's some other problem.

Reviewed By: emilsjolander

Differential Revision: D8350995

fbshipit-source-id: ff0a4f0e7a73848f6172c6108a0caee6efb43553
2018-06-12 04:11:47 -07:00
John Knox
8af2af6558 Never reuse CSR files
Summary:
If the app has an old CSR with data that is incompatible with sonar, we can't use it.
An example of this happening is when we moved the package name from organisation to common name in the certificate subject.
To get around this, always create a new one to guarantee it contains what we expect.

Reviewed By: emilsjolander

Differential Revision: D8350247

fbshipit-source-id: e53148fcddc47aa60e3daef5bbf36ce330a3b4e9
2018-06-12 04:11:47 -07:00
Daniel Buchele
f7d487dd76 fbshipit-source-id: 2cd940396d650342920b28835f6e672febe6b55c 2018-06-12 03:39:09 -07:00
Daniel Büchele
fbbf8cf16b Initial commit 🎉
fbshipit-source-id: b6fc29740c6875d2e78953b8a7123890a67930f2
Co-authored-by: Sebastian McKenzie <sebmck@fb.com>
Co-authored-by: John Knox <jknox@fb.com>
Co-authored-by: Emil Sjölander <emilsj@fb.com>
Co-authored-by: Pritesh Nandgaonkar <prit91@fb.com>
2018-06-01 11:03:58 +01:00