Ayende @ Rahien

Tobin Harris commented on It's the future now

Fri, 04 Jan 2008 10:14:04 GMT

Jon Thanks for the explanation, I've got it now :)

Ayende Rahien commented on It's the future now

Thu, 03 Jan 2008 19:24:31 GMT

Jon, You have _no idea_ how often I hit into this bug

Jon Skeet commented on It's the future now

Thu, 03 Jan 2008 19:21:07 GMT

I've just been looking into the method group version (i.e. InThe.Future(controller.LongRunningTask). It should work. It doesn't due to a bug in the compiler - it doesn't implement the spec correctly with regards to output type inference and method groups. It's a rather obscure bug, fortunately - unlikely to be a problem very often! Jon

Jeremy Gray commented on It's the future now

Thu, 03 Jan 2008 19:06:46 GMT

@Ayende - I hear ya. I was mostly just dreaming a bit and thinking of what it would be like if one could do that. Mind you, I'm not sure the language/compiler would actually limit you from supporting the implicit conversion in a useful number of cases. I have a LazyLoad of T class, for example, kicking around somewhere that supports conversion to T. Perhaps I'll have to dig it up and see what limits it would bump into.

Andrey Shchekin commented on It's the future now

Thu, 03 Jan 2008 18:04:28 GMT

Have you looked at the Parallel FX? I think they have a Future. Btw, futures and perl6's junctions make me wonder if there is a place in a language for things like that -- the X that transparently behaves as T for all operations on it except several special ones. Like 5 + future int => future int.

Ayende Rahien commented on It's the future now

Thu, 03 Jan 2008 17:49:49 GMT

Jeremy, You probably don't want to do that, and anyway you can't (unless they changed the limit on implicit conversion to interfaces.

Jeremy Gray commented on It's the future now

Thu, 03 Jan 2008 17:43:30 GMT

@Jay - Just imagine how beautiful it would be if Future of T implemented an implicit cast to T. :)

Dustin Campbell commented on It's the future now

Thu, 03 Jan 2008 15:19:22 GMT

Awesome! However, InThe should be renamed to BackToThe. That way, I can write this: Future future = BackToThe.Future(controller.LongRunningTask()); And of course, FutureInterceptor should be renamed to FluxCapacitor.

Jay R. Wren commented on It's the future now

Thu, 03 Jan 2008 15:04:02 GMT

I just find it very beautiful once I get my head wrapped around it.

Jon Skeet commented on It's the future now

Thu, 03 Jan 2008 14:59:54 GMT

Lambda or (ugly) anonymous methods both work, yes. I must admit I'm surprised that the method group version doesn't work though. I guess it's something deep inside the type inference bit of the spec which treats anonymous functions differently to method groups. That part of the spec is horrendous to read these days - it's all a lot more complicated for C# 3 than it was for C# 2. A lot more powerful, of course, and pretty much necessary for LINQ to work, but nightmarish to reason about. Just looking at the spec briefly, I would have expected 7.4.2.6 (second bullet) to work in this case. I'll investigate further when I don't have a screaming 19-month-old on my knee...

James Arendt commented on It's the future now

Thu, 03 Jan 2008 13:10:44 GMT

Francois's solution to simply pass the name of the method in, unfortunately, does not appear to work in this case. The lambda appears to be the only approach where type inferencing works.

Jon Skeet commented on It's the future now

Thu, 03 Jan 2008 12:36:40 GMT

Tobin, The point is to get other useful work done on the original thread, while something else happens on the LongRunningTask thread. When the original thread can't do any more useful work until the long running task has completed, it can ask for the value - which will block until it's ready.

Tobin Harris commented on It's the future now

Thu, 03 Jan 2008 12:25:36 GMT

Thanks Ayende. It looks like calling clients "block" whilst waiting for the Future to get it's result? I see that the result is calculated on another thread, but is that critical to this pattern? A synchronised method would enforce calling threads to queue up so that only one could execute the code at a time. So, both things appear to achieve the same objective? (Actually, I know I'm wrong on this, but just want to explain where I don't get it!)

Ayende Rahien commented on It's the future now

Thu, 03 Jan 2008 12:18:08 GMT

Tobin, It is executing in another thread, synchronized is another issue

Ayende Rahien commented on It's the future now

Thu, 03 Jan 2008 11:46:10 GMT

Not if I wanted to pass parameters

Tobin Harris commented on It's the future now

Thu, 03 Jan 2008 10:18:24 GMT

It looks cool, but I'm not sure I get it. Why not just mark LongRunningTask as synchronised? Sorry if it's a dumb question!

Jon Skeet commented on It's the future now

Thu, 03 Jan 2008 09:24:09 GMT

Regarding () => controller.LongRunningTask(), that should be fine. Perhaps you tried the C# 2 "equivalent": delegate { return controller.LongRunningTask(); } ? That wouldn't work in C# 2, but would work in C# 3 due to the enhanced type inference. But the answer from Francois is probably the best one :) Jon

Francois Tanguay commented on It's the future now

Thu, 03 Jan 2008 07:15:20 GMT

Regarding syntax, you could've used: InThe.Future(controller.LongRunningTask);

Ayende Rahien commented on It's the future now

Thu, 03 Jan 2008 05:41:55 GMT

James, Wow, you are correct. But I tried that, and it didn't work.

James Arendt commented on It's the future now

Thu, 03 Jan 2008 05:18:26 GMT

Future future = InThe.Future(() => controller.LongRunningTask()); You are incorrect in stating that you have to explicitly declare T for the method. The compiler can in fact correctly determine the type based on the lambda function. Jon's code was correct. Try it. :-)

Ayende Rahien commented on It's the future now

Thu, 03 Jan 2008 04:40:29 GMT

Jeremy, I am afraid not.

Ayende Rahien commented on It's the future now

Thu, 03 Jan 2008 04:38:13 GMT

The codethat you listed doesn't work, you need to explicitly state the T of the method. I find it ugly. Future future = InThe.Future(() => controller.LongRunningTask()); I am talking specifically about concurrent futures here, so threading is always involved. GetParameterValue() will be called immediately, changing the value of controller will not affect the future call. That is not something that I would push to production without some thought, mind you. I actully did push a a Future to production yesterday, but it was of the first, explicit variety.

Jeremy Gray commented on It's the future now

Wed, 02 Jan 2008 23:29:41 GMT

Oren, as much as I admit that I haven't yet had a chance to look at what I'm about to mention, I'm wondering if you have yet had any time to look at the ParallelFX CTP and its Tasks and Futures?

Thom commented on It's the future now

Wed, 02 Jan 2008 22:31:29 GMT

I made a half-arsed attempt at something a bit more transparent a while back: http://thom.org.uk/blog/FutureValuesWithCastlesDynamicProxy.aspx Given Jon's comment above, this is potentially even more aggravating, as consumers would have no indication at all that something odd is happening, but YMMV.

Jon Skeet commented on It's the future now

Wed, 02 Jan 2008 21:53:02 GMT

I'm afraid I don't like it, myself. When you call a method as a parameter, normal C# executes the method immediately. I like coding on "solid ground" where the rules of the language don't shift and change. I guess that's the argument against AOP in general, and normally I'm on AOP's side - this just feels one step too far for my liking. With C# you could easily have: Future future = InThe.Future(() => controller.LongRunningTask()); The addition of just 5 characters makes it much obvious that you're passing in a delegate, and that therefore the code may not get executed immediately. What happens in your code if you do something like: Future future = InThe.Future(controller.LongRunningTask(GetParameterValue())); ? Does GetParameterValue() get executed immediately, and LongRunningTask get executed "later"? What if I change the value of controller in the next line of code - might it change the invocation if the thread hasn't started yet, or not? What about the thread safety of InThe? Also bear in mind that futures don't *have* to have anything to do with multi-threading. I've got some LINQ code I'm working on at the moment which effectively lets you set up a load of data observers, then push some data, then get the values later. For instance: IDataProducer dp = new DataProducer(); IFuture count = dp.Count(); IFuture maxLength = dp.Max(x => x.Length); // etc dp.ProduceAndEnd(someListOfStrings); int realCount = count.Value; int realMaxLength = maxLength.Value; // etc The code was originally written for a slightly different situation, but I think it's a neat use case - and one which involves futures but explicit timing on a single thread. I wouldn't want each of the aggregates to end up running on a different thread here. Anyway, time to shut up now. Jon