Using C# 2.0 iterators to simplify writing asynchronous code (part 2)

re: Using C# 2.0 iterators to simplify writing asynchronous code (part 2)

Oleg Mihailik — Sun, 02 Apr 2006 11:56:34 GMT

Michael, I think your implementation of this idea is a little over-complex.

By the way, with Google and "Asynchronous iterators" query you can find:

http://www.google.com/search?q=asynchronous+iterators

1. My article on this idea: msmvps.com/blogs/79813.aspx

2. Your first article: blogs.msdn.com/michen/archive/2006/03/30/564671.aspx

3. Miguel de Icaza post about asynchronuos execution and iterators in Mono ASP.NET implementation.

And you can find, Miguel's post was first. And the Mono project is first place where this cool idea was used in C#. Strangely, but nobody detected that cool idea in Miguel's blog.

In my post (at Christmas) I had no feedback too.

I think the idea is very competitive, but the implementation and framework around it should be a lot stronger and simpler to be widely used. May be such asynchronous "chained" operation is good place for improvement at language level in future C# versions.

re: Using C# 2.0 iterators to simplify writing asynchronous code (part 2)

michen — Sun, 02 Apr 2006 12:42:24 GMT

Very interesting, I should have googled before posting this :)

Indeed, yours and Miguel de Icaza blogs describe almost the same usage as I described.

I believe the synchronization logic is necessary though - C#-generated iterator is not thread-safe, and both implementations (at least as described in blogs) suffer from the problem solved in my article: they do not handle correctly the case when async operation finishes before or at the same time when the thread that started it produces the value with 'yield return'. And this is not just theoretical problem - I've found this could happen with HttpWebRequest class.

The complexity of implementation is arguable, but with some added complexity in the library, it lets one write simpler code: by centralizing exception handling, ensuring finally block in the iterator is called, and avoiding unnecessary anonymous delegates in user code – the user writes simple sequential code (this is also the case for Miguel's version).

But anyway it is the same idea, thanks for letting me know – it was very educating to look at other implementations! I'm adding your and Miguels blogs to my RSS agregator :)

re: Using C# 2.0 iterators to simplify writing asynchronous code (part 2)

Oleg Mihailik — Sun, 02 Apr 2006 13:36:58 GMT

Michael, I understan you very well :-)

Actually I found previous Miguel's implementation AFTER my posting too. It was so sad at first time!

---

About threading issues.
Actually, my implementation is not fragile by race conditions. Let me show why.

Look here, it is asynchronous algorithm of Socket.BeginAccept/EndAccept:
http://blogs.gotdotnet.ru/personal/mihailik/PermaLink.aspx?guid=a9557a71-8e52-48ef-b867-d0f78e636e77

The core is iterator:

private IEnumerator<Invoke> AsyncListen(Action<Socket> yieldSocket, Invoke next)
{
while( true )
{
IAsyncResult acceptCompleted = null;
yield return delegate
{
acceptCompleted = tcpListener.BeginAcceptSocket(
delegate { next(); },
null);
};

Socket acceptedSocket = tcpListener.EndAcceptSocket(acceptCompleted);

yieldSocket(acceptedSocket);
}
}

Here you can see that it returns not IEnumerable "of int", but "of Invoke", and Invoke is actually delegate.

So, the things going more complex under the cover, but synctactic sugar hides this. Here is different parts of algorithm:

1. Preparing to Socket.BeginAccept
2. Calling Socket.BeginAccept
3. Stepping by IEnumerator.MoveNext
4. Calling Socket.EndAccept

Actually iterator code contains only (1) and (4).

BeginAccept (3) is not called from iterator code, but it is called from surround "framework" code. As you can see, iterator yields asynchronous delegate with BeginAccept call inside it. Iterator does not call BeginAccept, it is just delegate this call to surround "framework".

So, when iterator's code is stopped by yield, BeginInvoke is yet not called. It means iterator NEVER can execute next step BEFORE finishing priveous.

* * *

Also I have some ideas for C# language features for this problem. It may be automatic BeginOperation/EndOperation implementation, based on Operation() method.

Compiler may detect the places for "yield-step-points" inside hand-written Operation() method. For example:

ParsedRequest GetRequest(Socket socket)
{
...
Socket.Read(...);
...
return ...
}

The compiler may found calls to Socket.Read, and convert it to Socket.BeginRead/EndRead, splitted by yield-like-continuation.

Syntactically it may be something like:

async ParsedRequest GetRequest(Socket socket)

and it will be compiled into three methods: actual GetRequest and pair of BeginGetRequest/EndGetRequest generated by compiler.

re: Using C# 2.0 iterators to simplify writing asynchronous code (part 2)

michen — Sun, 02 Apr 2006 14:03:54 GMT

Thanks, I now understand how you code works - yes, it looks thread-safe.

***

About C# compiler doing the code transformation - this was exactly the same wish I've got too :)

The second thought was that LISP with its (arguably evil, but powerful) macro facility would allow implementing this in a library, rather than modifying core language. Unfortunately, I don't see a way to have LISP-like macro for a language with complex syntax like C#.

Interesting Finds

Jason Haley — Sun, 02 Apr 2006 14:23:47 GMT

Interesting Finds

Jason Haley — Mon, 03 Apr 2006 12:28:30 GMT

re: Using C# 2.0 iterators to simplify writing asynchronous code (part 2)

jasons — Thu, 05 Apr 2007 12:52:44 GMT

you both rock, my hat is off to both of you sirs!

thank you for your conversation, i find it very interesting and compelling!

re: Using C# 2.0 iterators to simplify writing asynchronous code (part 2)

John — Fri, 04 May 2007 03:45:00 GMT

Thanks for a great article. Most of the examples I've seen for using sockets don't deal with the real life issues such as the one you mention with HttpWebRequest. M(ost examples don't deal with packet fragmentation either, simply assuming that any aribitrary number of bytes they read is the entire message and can be converted to a string with a single call to an encoding function.) I appreciate the complication that you added to your code to make it more realistic.