- 09 May, 2016 4 commits
-
-
Lucian Grijincu authored
Reviewed By: meyering Differential Revision: D3277138 fbshipit-source-id: 7050d18c256ac15c8122d4af59aa31208b1466fd
-
Christopher Dykes authored
Summary: Due to some fun with the order MSVC does name lookup in templates, it ends up complaining that these are ambigious between folly::detail and folly::recordio_helpers::detail. The solution is to simply reference folly::detail explicitly. Reviewed By: yfeldblum Differential Revision: D3271606 fbshipit-source-id: e599ad8d8fe33b1e4ec0b838ddb5dfacfdf60159
-
Christopher Dykes authored
Summary: This fixes a few issues in the portability headers for MSVC. Not entirely sure how I managed to cause these in the first place, but this fixes them anyways. Reviewed By: yfeldblum Differential Revision: D3271859 fbshipit-source-id: 11a5d35246f29112563ee9079525aa37ced206ff
-
Philip Pronin authored
Summary: I would switch these to just use the intrinsic functions, but GCC 4.8 doesn't support them. MSVC supports the intrinsics, which is the primary reason for the switch. Reviewed By: yfeldblum Differential Revision: D3265572 fb-gh-sync-id: 3268f90d5234bdf77b3579504efd3dcd43f38aff fbshipit-source-id: 3268f90d5234bdf77b3579504efd3dcd43f38aff
-
- 07 May, 2016 1 commit
-
-
Andrii Grynenko authored
Summary: It's very unlikely that caller will handle such exceptions and FiberManager can proceed even if one task failed. DFATAL will ensure we still fail on such exceptions in debug builds. Reviewed By: yfeldblum Differential Revision: D3273573 fb-gh-sync-id: 55eba19c16429a3c89a2fdf5363fd4b55b3998a2 fbshipit-source-id: 55eba19c16429a3c89a2fdf5363fd4b55b3998a2
-
- 06 May, 2016 5 commits
-
-
Andrii Grynenko authored
Summary: Having singleton registered after registrationComplete() is called is not a hard failure. Replacing exception with ERROR, since we probably still want to avoid such situation. Reviewed By: yfeldblum Differential Revision: D3266376 fb-gh-sync-id: 8130d279775348c835265987c95189bd3d8106f9 fbshipit-source-id: 8130d279775348c835265987c95189bd3d8106f9
-
Christopher Dykes authored
Summary: I would switch these to just use the intrinsic functions, but GCC 4.8 doesn't support them. MSVC supports the intrinsics, which is the primary reason for the switch. Reviewed By: yfeldblum Differential Revision: D3265572 fb-gh-sync-id: f12d16b8f64cf48adcb97958d7ae88d56689a96f fbshipit-source-id: f12d16b8f64cf48adcb97958d7ae88d56689a96f
-
Christopher Dykes authored
Summary: Windows doesn't define a couple of functions. Reviewed By: yfeldblum Differential Revision: D2990676 fb-gh-sync-id: 1a1354bd7976cb8b4747436d6907d65210ba506c fbshipit-source-id: 1a1354bd7976cb8b4747436d6907d65210ba506c
-
Haijun Zhu authored
Summary: test console reports "address already in use" failure so add some randomness to it. Reviewed By: yfeldblum Differential Revision: D3265329 fb-gh-sync-id: a825cce787394783bb8d18d92385d2497b163385 fbshipit-source-id: a825cce787394783bb8d18d92385d2497b163385
-
Christopher Dykes authored
Summary: Windows doesn't have it, and it's used in a lot of places. Reviewed By: yfeldblum Differential Revision: D2997499 fb-gh-sync-id: fbf8f5f087b8f39197d5bf2177e4d34efd74631f fbshipit-source-id: fbf8f5f087b8f39197d5bf2177e4d34efd74631f
-
- 05 May, 2016 4 commits
-
-
Andrii Grynenko authored
Summary: Grouping all folly::ThreadLocal atfork hooks in one. This allows proper ordering between folly::ThreadLocal hooks and hooks added by other libraries (we always want folly::ThreadLocal hooks to be registered first). Reviewed By: ericniebler Differential Revision: D3262666 fb-gh-sync-id: 1aa928b9ddd484580f4a4a7b320e9e64164bb04a fbshipit-source-id: 1aa928b9ddd484580f4a4a7b320e9e64164bb04a
-
Andrii Grynenko authored
Summary: LoopKeepAlive can be useful to tell EventBase, that loop() shouldn't return even if there are no events registered, because some tasks will later be added via runInEventBaseThread. While at least one LoopKeepAlive is alive - EventBase::loop() behaves like EventBase::loopForever(). Reviewed By: yfeldblum Differential Revision: D3261706 fb-gh-sync-id: d91424d3d12cae11abd72cffdbd57f136f628dae fbshipit-source-id: d91424d3d12cae11abd72cffdbd57f136f628dae
-
Andrii Grynenko authored
Reviewed By: yfeldblum Differential Revision: D3244669 fb-gh-sync-id: 73fa4ecb0432a802e67ef922255a896d96f32374 fbshipit-source-id: 73fa4ecb0432a802e67ef922255a896d96f32374
-
Michael Lee authored
Summary: There are two places that still includes gflags/gflags.h: portability/GFlags.h and futures/exercises/Koan.h. Also removing gflags entirely from a couple of places which never reference it at all. Reviewed By: yfeldblum Differential Revision: D3203187 fb-gh-sync-id: e7725fbf2c4b3c475c0035e1b0e8c6e1227f277f fbshipit-source-id: e7725fbf2c4b3c475c0035e1b0e8c6e1227f277f
-
- 04 May, 2016 13 commits
-
-
Christopher Dykes authored
Summary: Windows doesn't have these functions under these names, so be nice to the code using it. Reviewed By: yfeldblum Differential Revision: D3003641 fb-gh-sync-id: 1657545af6975c96aea4a48c359250828b5921e0 fbshipit-source-id: 1657545af6975c96aea4a48c359250828b5921e0
-
Christopher Dykes authored
Summary: Windows has it, but all it does is define a few constants. Reviewed By: yfeldblum Differential Revision: D3002161 fb-gh-sync-id: a719faf391125522b2cb21471a56e8a9fe894225 fbshipit-source-id: a719faf391125522b2cb21471a56e8a9fe894225
-
Eric Niebler authored
Summary: `folly::Function` was an alias to a more complex type with template arguments that could not be deduced. For example, the call to `foo` below was failing to compile. ``` template <class R, class... As> void foo(folly::Function<R(As...)> f) { } int main() { foo( folly::Function<void(int)>{ [](int i){} } ); } ``` Rearrange the code so that folly::Function is no longer an alias, thus making its template arguments deducable. Reviewed By: luciang, spacedentist Differential Revision: D3256130 fb-gh-sync-id: fb403e48d161635b3b7f36e53b1679eb46cbfe7f fbshipit-source-id: fb403e48d161635b3b7f36e53b1679eb46cbfe7f
-
Andrii Grynenko authored
Summary: This diff implements two functions which can be used to bridge C++ asynchronous APIs with Python. 1. getExecutor(event_loop) allows extracting a folly::Executor-compatible object from Python event_loop. 2. wrapFuture wraps any folly::Future object in a Python Future object. Reviewed By: ambv Differential Revision: D2878731 fb-gh-sync-id: 83628b6b24d6039999f88c5de441e41064b2417e fbshipit-source-id: 83628b6b24d6039999f88c5de441e41064b2417e
-
Christopher Dykes authored
Summary: While the previous version did compile, it would generate warnings about symbols being defined in multiple places. Reviewed By: yfeldblum Differential Revision: D3255815 fb-gh-sync-id: 72f5079a3973a04bdc0b469b97ba46181e40353b fbshipit-source-id: 72f5079a3973a04bdc0b469b97ba46181e40353b
-
Christopher Dykes authored
Summary: MSVC doesn't have it, but Folly uses it, so implement it in the Builtins portability header. Reviewed By: yfeldblum Differential Revision: D3256123 fb-gh-sync-id: fd9ea1b6098d97cf1fde4732905bae9bde8cd8ad fbshipit-source-id: fd9ea1b6098d97cf1fde4732905bae9bde8cd8ad
-
Christopher Dykes authored
Summary: MSVC doesn't like it when you try to initialize a static in-class non-primitive constexpr member. It was only used in one place, so stick the definition in that function instead. Reviewed By: yfeldblum Differential Revision: D3255178 fb-gh-sync-id: e4a862a2662c4f5376c19fc52827cb2953f01e52 fbshipit-source-id: e4a862a2662c4f5376c19fc52827cb2953f01e52
-
Christopher Dykes authored
Summary: syscall() doesn't exist on Windows, but std::thread::id is standardized, and can do what we need it for, so use it instead. Reviewed By: yfeldblum Differential Revision: D3256064 fb-gh-sync-id: efddac82c117ccd8a53c8c93248529000b4326a5 fbshipit-source-id: efddac82c117ccd8a53c8c93248529000b4326a5
-
Christopher Dykes authored
Summary: MSVC doesn't like it, so the other uses were changed to .load() explicitly a while back, but this use has been added since then. Reviewed By: yfeldblum Differential Revision: D3255261 fb-gh-sync-id: 11d49902eb3ef7113a7c57cc760353554a487496 fbshipit-source-id: 11d49902eb3ef7113a7c57cc760353554a487496
-
Marcus Holland-Moritz authored
Summary: This is a workaround (maybe even the correct fix if it turns out that ASan can't detect this FP case) for the problem described in https://llvm.org/bugs/show_bug.cgi?id=27627 where a memory region previously allocated by a fiber stack can overlap with the region of an mmap'd file. Accessing parts of the mmap'd file close to the stack region will trigger a false positive ASan error. This change makes sure each fiber explicitly unpoisons its stack memory by calling __asan_unpoison_memory_region in an ASan-enabled build. Reviewed By: yhfung Differential Revision: D3257924 fb-gh-sync-id: 484062e80af67dfd39d2eaf3cbb52fa3483924eb fbshipit-source-id: 484062e80af67dfd39d2eaf3cbb52fa3483924eb
-
Pavlo Kushnir authored
Summary: this diff provides methods that allow to avoid temporaries while cloning IOBufs. Also optimizes move constructor a bit - there is no need to call `decrementRefCount`, check for self assignment, etc. Reviewed By: yfeldblum Differential Revision: D3250456 fb-gh-sync-id: 32b0180c28f36151c6786dba6f511b491b224200 fbshipit-source-id: 32b0180c28f36151c6786dba6f511b491b224200
-
Yedidya Feldblum authored
Summary: [Folly] Let `via` take a functor by universal reference. And perfect-forward the functor to the call to `then`. Reviewed By: fugalh Differential Revision: D3255684 fb-gh-sync-id: 1b46a70fb9de88d21d785c0ce4d9dd3078829f13 fbshipit-source-id: 1b46a70fb9de88d21d785c0ce4d9dd3078829f13
-
Christopher Dykes authored
Summary: The one header that doesn't split well. This is the last piece of the portability headers for Windows and is also the piece that has had the most thought put into it's design so-as to be as unintrusive as possible. Reviewed By: yfeldblum Differential Revision: D3046525 fb-gh-sync-id: 761a5e359bc130b95585608ee18fda94a30dae2c fbshipit-source-id: 761a5e359bc130b95585608ee18fda94a30dae2c
-
- 03 May, 2016 3 commits
-
-
Marcelo Juchem authored
Summary: `AsyncServerSocket::bind()` would not give information like port or family name when failing to bind a socket. This diff addresses that by including this information in the exception. Two additional helper methods were added to `SocketAddress` to retrieve both the port and the family name from a `sockaddr` structure. Reviewed By: ckwalsh, yfeldblum Differential Revision: D3249778 fb-gh-sync-id: 4edb28af5c211b7bf8d525b40844a5b0b6261e07 fbshipit-source-id: 4edb28af5c211b7bf8d525b40844a5b0b6261e07
-
Sven Over authored
Summary: This diff fixes a problem with passing move-only types to folly::via. Reviewed By: ericniebler Differential Revision: D3254906 fb-gh-sync-id: 8a9c703a8db0ccf20b9fb4fe9b80ad6cdcb3e388 fbshipit-source-id: 8a9c703a8db0ccf20b9fb4fe9b80ad6cdcb3e388
-
Yedidya Feldblum authored
Summary: [Folly] Deprecate `boost::mpl`. The `std` has equivalents; prefer them. Reviewed By: Gownta Differential Revision: D3247294 fb-gh-sync-id: 873697b7ea3ad069ff14662bc458a2e1cc840339 fbshipit-source-id: 873697b7ea3ad069ff14662bc458a2e1cc840339
-
- 02 May, 2016 5 commits
-
-
Michael Lee authored
Summary: It's there for a reason, so use it. Reviewed By: yfeldblum Differential Revision: D3249849 fb-gh-sync-id: e9fe330693a173acd987e0c8fd1f03a982c8e082 fbshipit-source-id: e9fe330693a173acd987e0c8fd1f03a982c8e082
-
Christopher Dykes authored
Summary: This is only an issue for the OSS HHVM build on OSX, where we have JEMalloc headers included directly. In the OSS HHVM build, we define `USE_JEMALLOC` globally if we have JEMalloc, so gate the portability implementation behind that. Reviewed By: mzlee Differential Revision: D3237449 fb-gh-sync-id: 07cf9b31114723ffd9f2b29cf449bee0ed8f5703 fbshipit-source-id: 07cf9b31114723ffd9f2b29cf449bee0ed8f5703
-
Neel Goyal authored
Summary: We should use the appropriate AsyncSocketExceptionType when firing SSLExceptions. This derives the type from the constructor args, and introduces a `NETWORK_ERROR` exception type. Open to suggestions on reusing something there. Additionally, rename getType() to getSSLError() to prevent hiding the AsyncSocketException::getType. Reviewed By: siyengar Differential Revision: D3241204 fb-gh-sync-id: de631dfb3554177d5bd561f4b91e767c882767d3 fbshipit-source-id: de631dfb3554177d5bd561f4b91e767c882767d3
-
Anirudh Ramachandran authored
Summary: This diff unifies the nearly-replicated call paths for ECDSA and RSA sign request/response/fallback/etc. into one generic futures-based sign API. Once this is tested, we should be able to remove ~500 lines of code from CryptoSSLRequestManager Depends on D3094660 Reviewed By: siyengar Differential Revision: D3116535 fb-gh-sync-id: 11c50d81dab39e5426679b5a172c1ece2039fc10 fbshipit-source-id: 11c50d81dab39e5426679b5a172c1ece2039fc10
-
Yedidya Feldblum authored
Summary: [Folly] Avoid glog when warning about `Singleton` double-registration. Because registration happens at static initialization time, long before main, and possibly long before glog is initialized. This makes a difference because, in some cases of double-registration, we can get a SIGSEGV with no message, because we are attempting to `LOG(FATAL)` when glog is uninitialized. What we would much rather have is a SIGABRT with a message. Reviewed By: meyering Differential Revision: D3245047 fb-gh-sync-id: 4c5dd9d25025f197d7c490ffbb429af5ccb82182 fbshipit-source-id: 4c5dd9d25025f197d7c490ffbb429af5ccb82182
-
- 30 Apr, 2016 1 commit
-
-
Andrii Grynenko authored
Summary: In D3241498 addTaskFuture was fixed to work with function returning void. This however changed addTaskFinally API to not allow finally functor which accepts Try<void>. folly::fibers generally supports Try<void> so there's no reason to force users to use folly::Unit instead of void for addTaskFinally too. Reviewed By: yfeldblum Differential Revision: D3243893 fb-gh-sync-id: d1df54738157d2019120103956f59b3971ba25ff fbshipit-source-id: d1df54738157d2019120103956f59b3971ba25ff
-
- 29 Apr, 2016 3 commits
-
-
Martin Martin authored
Summary: There's no Future<void>, you're supposed to use Future<Unit> instead. Unit has a "Lift" template to do the conversion. Reviewed By: andriigrynenko Differential Revision: D3241498 fb-gh-sync-id: db12d4f343685bc613b701e023c860c2c903ed4c fbshipit-source-id: db12d4f343685bc613b701e023c860c2c903ed4c
-
Martin Martin authored
Summary: Clang-format in preparation for other change Reviewed By: andriigrynenko Differential Revision: D3241297 fb-gh-sync-id: b7b26812e9e61c291d5c7bdb523df8f28f2d9b4f fbshipit-source-id: b7b26812e9e61c291d5c7bdb523df8f28f2d9b4f
-
Philip Pronin authored
Summary: As it might be used during global destruction (for example, to symbolize unhandled exception happened at that time). Reviewed By: luciang, ot Differential Revision: D3238303 fb-gh-sync-id: 39d8a6f99d95e700586349436e961f3624c95718 fbshipit-source-id: 39d8a6f99d95e700586349436e961f3624c95718
-
- 28 Apr, 2016 1 commit
-
-
Eric Niebler authored
use std::forward instead of std::move on objects whose types have been deduced; don't take the sizeof incomplete types Summary: Pretty sure std::forward is needed here instead of std::move. If you trace the call chain to see where the types of the objects come from, you'll see they can be deduced to be lvalues, so std::forward is the right choice. Also, moved some dicey looking code that appeared to be taking the size of some incomkplete types. Reviewed By: spacedentist Differential Revision: D3214199 fb-gh-sync-id: 778190ffb25a648b839760a3dddfad8dc6d41c88 fbshipit-source-id: 778190ffb25a648b839760a3dddfad8dc6d41c88
-