[PATCH] Use libpcl for portable coroutines

[Sam Liddicott]

* Volker Lendecke wrote, On 15/05/09 10:52:
> On Fri, May 15, 2009 at 10:35:42AM +0100, Sam Liddicott wrote:
>   
>> The risk seems to be in ensuring that the creator stack isn't activated
>> before the thing it waits on is complete - or that it can tell if this
>> occurs and switches to co_main to await the official callback.
>>     
>
> If I am not completely mistaken, this is the main problem
> when naively applying co-routines to solve problems with the
> nested event loops. From my point of view they don't really
> solve the fundamental problem I have with them: You call
> something you do not know is blocking/nested event/yielding.
> After that innocent call you can not rely on *anything*
> being the same as you left it before the call, anything
> might have happened in between.
>   
This is true. Co-routines are used so that anything CAN happen in
between, but as you say the caller may not realise.
> This is really threaded programming without mutexes.
>   
(comment below)
> Coroutines do have their place in making it easier to
> convert existing sync code to async, you don't have to split
> the routines up into separate functions. 
This is the only reason I am using them.
> But the caller of
> such a converted routine *must* be made aware that it is
> calling an async routine, otherwise you would end up with
> the same mess you started out to solve.
>   
Yes. I hadn't fully considered this because all my async functions are
of very limited scope, but you are right that it may be possible for a
ntvfs disconnect call to be processed before the ntvfs_connect has
finished processing.

I had missed the kind of awareness which is both "things might have
changed while I was suspended" as well as re-entrant functions.

Nested loops had the advantage there. Perhaps we need a mutex on the
read side and another one on the write side of a socket - but that's too
coarse, but if we put one on a vfs object so it can only process one
request and one callback at a time, then we end up with another queue of
requests at the ntvfs.

Hmmm. I'm glad you brought this up.

Sam