Re: Server-side async API implementation sketches

09.01.2011 04:15, Alice Bevan–McGregor kirjoitti:
> On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
>
>>> On 2011-01-08 13:16:52 -0800, P.J. Eby said:
>>>
>>> I've written the sketches dealing only with PEP 3148 futures, but 
>>> sockets were also proposed, and IMO there should be simple support 
>>> for obtaining data from wsgi.input.
>>
>> I'm a bit unclear as to how this will work with async. How do you 
>> propose that an asynchronous application receives the request body?
>
> In my example https://gist.github.com/770743 (which has been 
> simplified greatly by P.J. Eby in the "Future- and Generator-Based 
> Async Idea" thread) for dealing with wsgi.input, I have:
>
> future = environ['wsgi.executor'].submit(environ['wsgi.input'].read, 
> 4096)
> yield future
>
> While ugly, if you were doing this, you'd likely:
>
> submit = environ['wsgi.executor'].submit
> input_ = environ['wsgi.input']
>
> future = yield submit(input_.read, 4096)
> data = future.
>
> That's a bit nicer to read, and simplifies things if you need to make 
> a number of async calls.
>
> The idea here is that:
>
> :: Your async server subclasses ThreadPoolExecutor.
>
> :: The subclass overloads the submit method.
>
> :: Your submit method detects bound methods on wsgi.input, sockets, 
> and files.
>
> :: If one of the above is detected, create a mock future that defines 
> 'fd' and 'operation' attributes or similar.
>
> :: When yielding the mock future, your async reactor can detect 'fd' 
> and do the appropriate thing for your async framework. (Generally 
> adding the fd to the appropriate select/epoll/kqueue readers/writers 
> lists.)
>
> :: When the condition is met, set_running_or_notify_cancel (when 
> internally reading or writing data), set_result, saving the value, and 
> return the future (filled with its data) back up to the application.
>
> :: The application accepts the future instance as the return value of 
> yield, and calls result across it to get the data. (Obviously writes, 
> if allowed, won't have data, but reads will.)
>
> I hope that clearly identifies my idea on the subject. Since async 
> servers will /already/ be implementing their own executors, I don't 
> see this as too crazy.
-1 on this. Those executors are meant for executing code in a thread 
pool. Mandating a magical socket operation filter here would 
considerably complicate server implementation.
>
>
> - Alice.
>
>
> _______________________________________________
> Web-SIG mailing list
> [email protected]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: 
> http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi

_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org