- 15 Jun, 2015 1 commit
-
-
Bin Wang authored
-
- 12 Jun, 2015 10 commits
-
-
Praveen Kumar authored
Summary: Directly pass the arguments to respective constructors. Instead of first making temporary and then pass that. Closes #218 Reviewed By: @JoelMarcey Differential Revision: D2151582 Pulled By: @sgolemon
-
Praveen Kumar authored
Summary: Defaulted (*=default*ed) default constructors are better because they can be constexpr and/or noexcept when C++ Standard thinks it is right to do so. And they remain user-declared rather than user-provided. Regarding *=default*ed default constructor, benifit is that the work might be done during compilation and we might not need to worry about exception paths. And for destructors, apart from that that =defaulted definition is in sync with defaulted default constructor we might discover that in some cases "() {}" might be ill-formed when "= default;" compiltion indicates so. If =defaulted definition for destructor doesn't do any harm then why not go for it. Closes #216 Reviewed By: @yfeldblum Differential Revision: D2145322 Pulled By: @sgolemon -
Praveen Kumar authored
Summary: We might be doing: 1) Create a temporary 2) Copy/Move out of it 3) Destroy that temporary. Which isn't needed in many places. And copy/move elision doesn't work for a temporary bound to a reference. We can forward arguments, directly. To get the work done three constructors were added. Closes #222 Reviewed By: @JoelMarcey, @yfeldblum Differential Revision: D2151731 Pulled By: @sgolemon
-
Misha Shneerson authored
Summary: To be able to use fiber lock in thrift Reviewed By: @brianwatling, @yfeldblum Differential Revision: D2149936
-
Yablonskyy@axilera.com authored
Summary: parseLeadingNumber does not contain EOS validation and raise an exception when '/sys/devices/system/cpu/cpu0/index0/shared_cpu_list' contains only one number like '0'. Closes #207 Reviewed By: @yfeldblum Differential Revision: D2148015 Pulled By: @sgolemon
-
Hans Fugal authored
Summary: Some internal malloc shims broke on using folly::ThreadLocal, so only do that for `__APPLE__`. Reviewed By: @brianwatling Differential Revision: D2151318
-
Nicholas Ormrod authored
Summary: Clang warns when types with vtables are memcpy'd. If the type has declared itself to be relocatable, then this is the desired behavior. If the type has not declared itself to be relocatable, then the memcpy codepath is dead. However, the dead codepath is still instantiated (it's inside an if block with a static check, but c++ doesn't have static-if), so the compiler spits out a nasty warning anyways. Each memcpy reference inside of fbvector has been void-ified. I have looked at all the codepaths leading to the memcpys, and see that they have isRelocatable or isTriviallyCopyable checks. Reviewed By: @markisaa Differential Revision: D2148286
-
Alan Frindell authored
Summary: As in title Reviewed By: @djwatson Differential Revision: D2151092
-
Nicholas Ormrod authored
Summary: For standard containers, assignment tries to reuse heap space. Dynamic assignment does not - it calls destroy(), and then reconstructs a new dynamic. In the case that the old and new types are the same (eg assigning a dynamic-vector to a dynamic-vector) we can call through to the underlying type's assignment operator. Reviewed By: @jdelong Differential Revision: D2148093
-
Woo Xie authored
Summary: this taks advantage of the SSL_write_iovec function to improve CPU. According our testing, it saves 10+% CPU. Reviewed By: @djwatson Differential Revision: D2119223
-
- 11 Jun, 2015 14 commits
-
-
Fifi Lyu authored
Summary: Folly still continue to build and work on earlier boost versions(boost < 1.56). **boost::context::make_fcontext() change history:** * __1.55:__ fcontext_t * make_fcontext( void * sp, std::size_t size, void(* fn)(intptr_t) ); * __1.56:__ fcontext_t make_fcontext(void* sp,std::size_t size,void(*fn)(intptr_t)); **boost doc:** http://www.boost.org/doc/libs/1_55_0/libs/context/doc/html/context/context/boost_fcontext.html http://www.boost.org/doc/libs/1_56_0/libs/context/doc/html/context/context/boost_fcontext.html Closes #205 Closes #210 Reviewed By: @jwatzman Differential Revision: D2148069 Pulled By: @sgolemon
-
Sara Golemon authored
Summary: Some OSs have python named according to a version ID e.g. `python2.7` without a symlink from plain `python` Use autotool's AM_PATH_PYTHON to search for a suitable interpreter and use that to generate the *Tables.cpp files. Closes #109 Reviewed By: @yfeldblum Differential Revision: D2147977
-
Alexander Böhn / FI authored
Summary: On non-Linux systems, the autotools-based build system conditionally appends `detail/Clock.h` to `libfollybase_la_SOURCES` – even though that file is in there statically no matter what (as per [line 46](https://github.com/facebook/folly/blob/master/folly/Makefile.am#L46)), which causes the `install` command to error out trying to install the file twice, during `make install`… this patch takes out the conditional append. Closes #201 Reviewed By: @yfeldblum Differential Revision: D2148004 Pulled By: @sgolemon
-
Hans Fugal authored
Summary: OSX doesn't support C++11's `thread_local`. :-/ (yet? http://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports/29929949#29929949) We have `FOLLY_TLS` in `Portability.h` https://github.com/facebook/folly/blob/master/folly/Portability.h#L163-L175 So replace the usages of `thread_local` with `FOLLY_TLS`. But `__thread` is not drop-in compatible with `thread_local`, specifically the former requires global storage and needs a constexpr initializer, and a trivial destructor. `futures/QueuedImmediateExecutor` now uses `folly::ThreadLocal` (because `std::queue` has a non-trivial destructor). It might end up in one more alloc, per thread. I also rearranged the code to clarify the fact that although there may be many `QueuedImmediateExecutor`s, they all share the same queue per thread. I didn't use `folly::ThreadLocal` for fibers, because I thought it might be too expensive. But now I'm not so sure. I had to do the "check for default and then initialize" thing because of the requirement for constexpr initialization for `__thread` (and therefore `FOLLY_TLS`). Reviewed By: @jsedgwick Differential Revision: D2140369
-
Hans Fugal authored
Summary: Something's broken here, will track fixing in #7372389 Reviewed By: @jsedgwick Differential Revision: D2144077
-
Hans Fugal authored
Summary: They don't pass, but they build! Reviewed By: @jsedgwick Differential Revision: D2141717
-
Hans Fugal authored
Summary: Discard a result but propagate an exception. cf https://www.facebook.com/groups/715931878455430/permalink/879624552086161/ Reviewed By: @sammerat Differential Revision: D2144567
-
Woo Xie authored
Summary: This fucntion will be re-used for different SSL write functions in future. Reviewed By: @djwatson Differential Revision: D2117529
-
Hans Fugal authored
Summary: OSX apparently knows better than all of us plebes, and got rid of anonymous semaphores. Rather than try to work around that directly, I just switched to folly::LifoSem, which seems like a not-terrible idea anyway. Reviewed By: @jsedgwick Differential Revision: D2143566
-
Hans Fugal authored
Summary: ((not yet) more performant) sugar for `via(&x).then(func)` Reviewed By: @hannesr Differential Revision: D2131246
-
Tudor Bosman authored
Summary: Give IOBuf a copy constructor, which clones the whole chain. (IOBufs have shared pointer semantics). You could argue for cloning one single IOBuf, but cloning the whole chain has the nice side effect of making Thrift structures with IOBufs in them copyable, so there's that. Reviewed By: @djwatson Differential Revision: D2127209
-
James Sedgwick authored
Summary: Next step towards killing RequestEventBase hackery. Use EBs from global IO executor instead Reviewed By: @fugalh Differential Revision: D2123142
-
James Sedgwick authored
Summary: this is going to be a really common pattern, so I'm providing a shortcut Reviewed By: @fugalh Differential Revision: D2146008
-
James Sedgwick authored
Summary: No reason to go through the whole Promise rigamarole. Add an appropriate Core ctor and use that to make a completed Future with just the core alloc Note the big win in the `constantFuture` benchmark. ``` Before: ============================================================================ folly/futures/test/Benchmark.cpp relative time/iter iters/s ============================================================================ constantFuture 120.50ns 8.30M promiseAndFuture 91.99% 130.98ns 7.63M withThen 28.17% 427.77ns 2.34M ---------------------------------------------------------------------------- oneThen 430.48ns 2.32M twoThens 58.03% 741.86ns 1.35M fourThens 31.85% 1.35us 739.97K hundredThens 1.61% 26.80us 37.32K ---------------------------------------------------------------------------- no_contention 4.58ms 218.48 contention 83.70% 5.47ms 182.86 ---------------------------------------------------------------------------- throwAndCatch 8.09us 123.55K throwAndCatchWrapped 94.43% 8.57us 116.67K throwWrappedAndCatch 154.69% 5.23us 191.12K throwWrappedAndCatchWrapped 614.06% 1.32us 758.70K ---------------------------------------------------------------------------- throwAndCatchContended 967.54ms 1.03 throwAndCatchWrappedContended 103.48% 935.04ms 1.07 throwWrappedAndCatchContended 148.24% 652.70ms 1.53 throwWrappedAndCatchWrappedContended 14313.28% 6.76ms 147.94 ============================================================================ After: ============================================================================ folly/futures/test/Benchmark.cpp relative time/iter iters/s ============================================================================ constantFuture 69.11ns 14.47M promiseAndFuture 55.12% 125.37ns 7.98M withThen 16.49% 419.18ns 2.39M ---------------------------------------------------------------------------- oneThen 370.39ns 2.70M twoThens 55.11% 672.05ns 1.49M fourThens 29.00% 1.28us 782.89K hundredThens 1.23% 30.22us 33.09K ---------------------------------------------------------------------------- no_contention 4.56ms 219.46 contention 82.82% 5.50ms 181.77 ---------------------------------------------------------------------------- throwAndCatch 8.30us 120.42K throwAndCatchWrapped 96.40% 8.61us 116.08K throwWrappedAndCatch 162.66% 5.11us 195.89K throwWrappedAndCatchWrapped 680.39% 1.22us 819.36K ---------------------------------------------------------------------------- throwAndCatchContended 979.17ms 1.02 throwAndCatchWrappedContended 103.09% 949.84ms 1.05 throwWrappedAndCatchContended 153.55% 637.71ms 1.57 throwWrappedAndCatchWrappedContended 10468.47% 9.35ms 106.91 ============================================================================ ``` Reviewed By: @fugalh, @hannesr Differential Revision: D2144664
-
- 10 Jun, 2015 7 commits
-
-
Praveen Kumar authored
Summary: Use of std::max from libc++ resulted in error. std::max found type of its arguments diffrent whereas it expected them to be same. This diff fix the error. Closes #223 Reviewed By: @yfeldblum Differential Revision: D2144639 Pulled By: @sgolemon
-
Yadwinder Grewal authored
Summary: Closes #211 Reviewed By: @Gownta, @lbrandy Differential Revision: D2144702 Pulled By: @sgolemon
-
Austin McKinley authored
Summary: Closes #202 Reviewed By: @paulbiss Differential Revision: D2144850 Pulled By: @sgolemon
-
Ed Baunton authored
Summary: Minor typo when referencing `std::allocator` Closes #84 Reviewed By: @yfeldblum Differential Revision: D2144830 Pulled By: @sgolemon
-
Stewart Henderson authored
Summary: Closes #212 Reviewed By: @JoelMarcey, @paulbiss Differential Revision: D2144749 Pulled By: @sgolemon
-
Praveen Kumar authored
Summary: checked the sense Closes #224 Reviewed By: @paulbiss Differential Revision: D2144508 Pulled By: @sgolemon
-
Hannes Roth authored
Summary: I figured this test would be useless since it tests a check added before everything was converted to FSM. But since it appears to fail on Mac OS X, it might be useful to have after all. Reviewed By: @fugalh Differential Revision: D2143500
-
- 09 Jun, 2015 8 commits
-
-
woo authored
-
James Sedgwick authored
Summary: ^ Test Plan: OK Reviewed By: yfeldblum@fb.com Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2140212 Signature: t1:2140212:1433877717:86b7bf372091b455cdb25a377451e1ed4e21f50d
-
Sara Golemon authored
-
Dave Watson authored
Summary: Adds a StartTLS mode to AsyncSSLSocket. Previously I could only find anyone doing something like this by using AsyncSocket, calling detachFd, then creating a new AsyncSSLSocket, and calling sslConn/sslAccept. That had a couple downsides: 1) All pointers to the previous AsyncSocket become invalid and similarly 2) have to be super careful reads/writes happen on the correct socket, are flushed before changing socket types, etc. This makes it super easy to just use the same AsyncSSLSocket for everything: a) Create AsyncSSLSocket in StartTLS mode b) send/recv anything c) Call sslAccept/sslConn. Existing writes are still flushed in the correct order, any additional writes are buffered until handshake completes d) Start receiving encrypted data. I made it a new mode (vs. the default), since it seems bad to unintentionally send unencrypted data. Use case is easy secure thrift upgrade (similar to how current kerberos does it) Test Plan: New unittest Reviewed By: afrind@fb.com Subscribers: doug, ssl-diffs@, folly-diffs@, yfeldblum, chalfant, haijunz, andrewcox, alandau, alikhtarov, jsedgwick, simpkins FB internal diff: D2120114 Signature: t1:2120114:1433798448:caeddc8feb6cc10fb34200ba97ea323bcaf09f7a
-
Hans Fugal authored
Summary: Because https://github.com/google/double-conversion/commit/64702b40a2499702f9157ef015f0da6e006114bf If this breaks an existing checkout, it is because you have an old version of double-conversion now. Go ahead and `rm -rf` it, or start with a clean folly clone. Test Plan: Clean repo, `./bootstr<tab>`. Reviewed By: jsedgwick@fb.com Subscribers: exa, folly-diffs@, yfeldblum, chalfant FB internal diff: D2136836 Signature: t1:2136836:1433874889:6f6c6a7bd337e052c088aabf89955e9b21b1d8e1
-
Anton Likhtarov authored
Summary: GuardedPageAllocator now maintains a process-wide cache of preallocated stacks with guard pages. We can't create too many of these, since each stack has the overhead of two memory mappings. Once we run out of preallocated stacks we simply fallback on the default allocator. Test Plan: unit tests perflab TAO unit tests Reviewed By: pavlo@fb.com Subscribers: zhuohuang, trunkagent, sameen, folly-diffs@, yfeldblum, chalfant FB internal diff: D2129510 Tasks: 7319041 Signature: t1:2129510:1433542031:324942af3c9813344c1b331ee2c9b66c4bfa3f03
-
Hannes Roth authored
Summary: For D2099047 (matthieu) and also for symmetry. Can re-use most of the code, also refactored it a bit (using an empty base case). Test Plan: Run all the tests. Will add some more before committing. Reviewed By: jsedgwick@fb.com Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant, matthieu FB internal diff: D2131515 Signature: t1:2131515:1433776852:544166fbfdfabf6760fd78f87821290e17e6e4a3
-
James Sedgwick authored
Summary: unused, caused circular dep issues Test Plan: compiles Reviewed By: mzlee@fb.com Subscribers: subodh, folly-diffs@, yfeldblum, chalfant FB internal diff: D2135780 Signature: t1:2135780:1433786607:015cfa9bb14472f55f80467f2cfeb7426be9f7ea
-
