<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 3, 2015 at 11:24 AM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 3/3/2015 12:51 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Mar 3, 2015 at 8:53 AM, Shankar Kalpathi Easwaran <<br>
<a href="mailto:shankarke@gmail.com" target="_blank">shankarke@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
================<br>
Comment at: include/lld/Core/Parallel.h:77<br>
@@ +76,3 @@<br>
+/// <a href="https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01389.html" target="_blank">https://gcc.gnu.org/ml/gcc-<u></u>patches/2014-05/msg01389.html</a><br>
+template<typename T> class Future {<br>
+public:<br>
----------------<br>
there is only one usage of Future with lld::File, Why do we want to make<br>
this a template ?<br>
</blockquote>
<br>
I didn't plan to implement a future. I first tried to do that all within<br>
FileArchive using mutex and condition variables, and then realized that<br>
that's too low-level multi-thread programming which is pretty error-prone.<br>
<br>
If you are familiar with multi-thread programming, futures are basic<br>
building block of high-level multi-thread programming. It's a rendezvous<br>
point of a producer thread and a consumer thread. I built a basic block<br>
here. Replacing T of this Future class with File * is weird.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
================<br>
Comment at: lib/ReaderWriter/FileArchive.<u></u>cpp:63-69<br>
@@ -62,8 +62,9 @@<br>
{<br>
std::lock_guard<std::mutex> lock(_mutex);<br>
auto it = _preloaded.find(memberStart);<br>
if (it != _preloaded.end()) {<br>
- std::future<const File *> &future = it->second;<br>
- return future.get();<br>
+ std::unique_ptr<Future<const File *>> &p = it->second;<br>
+ Future<const File *> *future = p.get();<br>
+ return future->get();<br>
}<br>
}<br>
----------------<br>
The _preloaded map could get resized here ? Can we resize the map in<br>
advance since we know how many members are in the archive ?<br>
<br>
</blockquote>
There's no such function like resize defined for std::map because of the<br>
nature of the map. It's a balanced tree, there's no such notion like making<br>
room for future use.<br>
</blockquote></div></div>
I was hinting to make this a unordered_map which has a reserve function in it.</blockquote><div><br></div><div>So, as I wrote in the previous mail, the number of items that the map will contain is limited. I don't see a need to add more code to reserve room in the map. I'm planning to do performance profiling and make things faster. Let's not do micro-optimization at this moment.</div></div></div></div>