Yes, this is definitely on our list. <br><br>-James<br><br><div class="gmail_quote">On Sun, Dec 13, 2009 at 11:58 AM, YC <span dir="ltr"><<a href="mailto:yinso.chen@gmail.com">yinso.chen@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On a related note - does it make sense to integrate futures with the events framework? <br><br> Seems like touch is similar to sync.<br><br>Cheers,<br><font color="#888888">yc<br><br></font><div class="gmail_quote"><div><div></div><div class="h5">On Sun, Dec 13, 2009 at 7:57 AM, James Swaine <span dir="ltr"><<a href="mailto:james.swaine@gmail.com" target="_blank">james.swaine@gmail.com</a>></span> wrote:<br> </div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">Right. You won't have the problem Sam talks about where you've forced a computation to finish on a separate OS thread than the one you originally started on. Code in a future will always execute on the same OS thread (except for the unsafe primitive invocations), even if you touch it before it's finished. In that case, the runtime OS thread will do whatever unsafe work was blocking the future, then signal the future OS thread that it can resume. Then the runtime OS thread blocks waiting for the future thread to terminate (or ask for another primitive invocation).<br> <br>One thing to worry about is touching a future before a parallel thread has had a chance to discover it, in which case the whole future will actually be run on the runtime thread. I don't think this would really ever be a problem in practice, however, because if your code wants to touch the future that quickly, you probably didn't need to do the computation in parallel in the first place.<br> <br>The operating system can arbitrarily decide to move threads from one processor to another but there's little we can do about that. We can use affinity masking to politely suggest that the OS keep threads bound to specific processors/cores, but even then it's still <br> free to schedule them however it wants.<br><font color="#888888"><br>-James <br></font><div><div></div><div><br><div class="gmail_quote">On Sun, Dec 13, 2009 at 9:10 AM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On Sun, Dec 13, 2009 at 8:40 AM, Sam TH <<a href="mailto:samth@ccs.neu.edu" target="_blank">samth@ccs.neu.edu</a>> wrote:<br> > I thought that when a future gets `touch'ed, if<br> > it isn't finished, the remainder of the computation runs in the<br> > continuation (and thus thread) of the `touch'. If I'm wrong about<br> > that, then my worries are assuaged.<br> <br> </div>That's roughly what happens when the future was blocked (technically,<br> it does some rendez vous with the runtime thread instead of copying<br> the state over, but that's something that shouldn't really matter from<br> the api level), but when the future is not blocked, it just keeps<br> running merrily along.<br> <font color="#888888"><br> Robby<br> </font></blockquote></div><br> </div></div><br></div></div><div class="im">_________________________________________________<br> For list-related administrative tasks:<br> <a href="http://list.cs.brown.edu/mailman/listinfo/plt-dev" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-dev</a><br> <br></div></blockquote></div><br> </blockquote></div><br>