- 12 Jun, 2015 4 commits
-
-
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 15 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
-
Woo Xie authored
Summary: my D2097198 break the project relying on old glibc Test Plan: compling Reviewed By: wez@fb.com Subscribers: trunkagent, fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2135297 Tasks: 7283522 Signature: t1:2135297:1433791259:8b82b8d9b16da32be54c0dff1214fa20c94840e2
-
Alan Frindell authored
Summary: This allows an EventBase to exit loop() even if there are pending timeouts in the timer (make sure to cancelAll before deleting!) Test Plan: Unit tests Reviewed By: davejwatson@fb.com Subscribers: doug, folly-diffs@, yfeldblum, chalfant FB internal diff: D2111942 Signature: t1:2111942:1432934212:7ac1973bdbbfdbda714699ab373618399f29ef76
-
Dave Watson authored
Summary: proxygen/facebook/httpserver/filter/StatsFilter expects the threadlocal stats_ variable to be initialized before any requests, and destroyed on the same thread. There were two issues: 1) addObserver was being called after bind(), so it was possible to get some requests before the stats_ variable was initialized. Moved up the observer, should fix it (although I don't have a repro for this) 2) on server stop(), sometimes the observer onServerStop() callback was called, but the eventBase had already stopped. The IOThreadPoolExecutor eventually deleted the eventBase, causing consumeUntilDrained to be called, but in the main thread, and not in the eventBase's thread. I'm not as sure about this fix, hopefully @jsedgwick can chime in: I explicitly deleted the eventBase on the eventBase thread before join. Here's the stack for this issue: P19866015 Reviewed By: shiva@fb.com Subscribers: doug, fugalh, bmatheny, folly-diffs@, yfeldblum, chalfant, shiva, jsedgwick FB internal diff: D2132208 Signature: t1:2132208:1433537787:4379ba50a908ca6f19924c2339876afaf663364c
-
James Sedgwick authored
Summary: Based on new FileRegion interface Test Plan: ran it, streamed lots of files. I have found an obscure way to break it but I don't think it's a FileRegion issue, rather a pipeline/bootstrap issue. Still digging Reviewed By: hans@fb.com Subscribers: fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2088094 Signature: t1:2088094:1432758904:0f1e5765dbedea5ddbe047db50e7b632cfb0c053
-
James Sedgwick authored
Summary: similar to D2050808, but move the functionality into AsyncSocket itself so that you have a consistent interface and contiguous writes for a single file Test Plan: added unit, will hook this up to a file server example next Reviewed By: davejwatson@fb.com Subscribers: fugalh, net-systems@, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2084452 Signature: t1:2084452:1433181933:175158618966706db00bf6620cc86ae145d04ecf
-
Steve O'Brien authored
Summary: Need to be more explicit about types; it was trying to add types deduced to be `unsigned long` + `long` which didn't agree and could be an overflow. Be explicit anyway about the types involved. Appease Clang, and also make the code more obvious to the reader. Test Plan: Tried with gcc 4.9, clang 3.5, clang 3.6. Reviewed By: yfeldblum@fb.com Subscribers: mathieubaudet, maoy, folly-diffs@, yzhan, yfeldblum, chalfant FB internal diff: D2134814 Tasks: 7337462 Signature: t1:2134814:1433726862:5dd80b198187c610f793e26160919922863a22a2 Blame Revision: D1934777
-
Steve O'Brien authored
Summary: To estimate length of a number's base-10 length in digits, use insn `bsrq` (Bit Scan Reverse) to count significant bits. From that, approximate base-10 length. Tries to avoid branchiness, expensive math, and loops. Test Plan: 1) Tested correctness by comparing results with `snprintf` and ensuring same string lengths. Tested at each boundary condition (2^k)-1, 2^k, (2^k+1); and similar for base 10. 2) Benchmarked with gcc 4.9 and clang 3.5. Before/after values are millions operations / sec GCC 4.9 Clang 3.5 1 111.09 111.7 1.005 1 115.36 393.81 3.414 2 115.36 111.7 0.968 2 115.36 393.89 3.414 3 114.91 111.34 0.969 3 111.09 393.56 3.543 4 114.91 111.34 0.969 4 111.09 393.86 3.545 5 115.36 111.36 0.965 5 111.09 392.18 3.530 6 99.99 104.32 1.043 6 103.43 393.74 3.807 7 83.31 84.71 1.017 7 81.06 268.39 3.311 8 76.9 78.23 1.017 8 76.91 268.26 3.488 9 62.48 68.26 1.093 9 65.56 190 2.898 10 59.98 63.65 1.061 10 61.17 190.54 3.115 11 50.6 55.87 1.104 11 54.54 148.03 2.714 12 47.19 51.7 1.096 12 50.84 148.57 2.922 13 40.53 46.99 1.159 13 43.33 115.91 2.675 14 40.48 43.42 1.073 14 41.5 115.97 2.794 15 34.92 40.21 1.151 15 37.27 94.89 2.546 16 33.49 37.51 1.120 16 35.77 94.88 2.653 17 29.89 35.02 1.172 17 31.7 80.67 2.545 18 29.11 32.98 1.133 18 30.76 80.63 2.621 19 26.58 31.05 1.168 19 28.22 70.15 2.486 20 25.64 29.38 1.146 20 27.96 70.16 2.509 Reviewed By: ldbrandy@fb.com Subscribers: dancol, trunkagent, marcelo, chalfant, maoy, folly-diffs@, yzhan, yfeldblum FB internal diff: D1934777 Signature: t1:1934777:1433523486:3acbe7ed9c9560c44194f854754529041eaa289d
-
