4 ms·
I was just throwing ideas out there, not really thinking it through. :) Although you're absolutely right about waitForAll() in that example, there is a point to
by pmjordan 16y ago
I was just throwing ideas out there, not really thinking it through. :) Although you're absolutely right about waitForAll() in that example, there is a point to that sort of function, say if you wanted to add a timeout. Or you could have a waitForAny() function - useful if you only need one of the futures to finish before proceeding.
get() vs. wait() is admittedly a question of preference. Personally, I'd keep them separate and even go so far as to have it warn you if you called get() without a wait() or a successful isReady() or so on that future. It keeps the suspensions explicit and the intentions clear. It's a bit like explicit vs implicit transactional systems.
- bruceboughton 16y agoOut of interest, is this any different to WaitHandles + async delegates in .NET? Doesn't look like it to me but I could be missing something: Func<string> reader = read; IAsyncResult future_x = reader.BeginInvoke(null, null) IAsyncResult future_y = reader.BeginInvoke(null, null) WaitHandle.WaitAll(new[] { future_x.AsyncWaitHandle, future_y.AsyncWaitHandle }); // takes optional timeout string x = reader.EndInvoke(future_x); string y = reader.EndInvoke(future_y); write(x + y);
- pmjordan 16y agoLooks like it's essentially the same type of programming model, although I have a feeling WaitHandle.WaitAll() just blocks the current thread. In the ideal case, it would internally call the event loop coroutine and process other events instead without sending the thread to sleep. Thread scheduling involves system (kernel) calls, coroutines are purely userspace, just like node.js's async callback mechanism.