Re: Collating follow-up on the future of WSGI

--===============5646074409608240776==
Content-Type: multipart/alternative; boundary=001a113f16da3ee8960529c5ec62

--001a113f16da3ee8960529c5ec62
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 20, 2016 at 1:57 AM Robert Collins <[email protected]>
wrote:

> On 20 January 2016 at 12:04, Benoit Chesneau <[email protected]> wrote:
>
> >
> > not at all. But I made the assumption that the wsgi server maintained a
> > thread directly or not where the python application is running .
> >
> > In any case there is some sort of wrapping done in the same
> thread/process
> > where the python application is running. And then nothing stop to give
> the
> > socket away to the application and tell to the server to stop to
> communicate
> > with it.
>
> What socket?
>
> Data could be being passed by shm, for instance.
>
> -Rob
>
>
While shared memory would be quite a bad idea, then why not. I still don't
see why having a way to upgrade the connection can't be done.

Call it I/O resource or Socket, the issue is the same. At the end nothing
stop the server to pass the control to the app. If we forget the socket
(which is btw the simplest design) then the server could stop to control
the I/O resource when the application ask it to do it. At some point either
a garbage collection or a basic resource return/claim flow could be used to
definitely free the resource.

The thing behind that is that it would allow the WSGI spec to only focus on
providing a strict gateway workflow without forcing the application to
adopt a concurrency model aync or not.

- benoit.

--001a113f16da3ee8960529c5ec62
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Jan 20, 2016 at 1:57 AM Robert Collins &lt;<a href=3D"mailto:robertc@robe=
rtcollins.net">[email protected]</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">On 20 January 2016 at 12:04, Benoit Chesneau &lt;<a hr=
ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>=
&gt; wrote:<br>
<br>
&gt;<br>
&gt; not at all. But I made the assumption that the wsgi server maintained =
a<br>
&gt; thread directly or not where the python application is running .<br>
&gt;<br>
&gt; In any case there is some sort of wrapping done in the same thread/pro=
cess<br>
&gt; where the python application is running. And then nothing stop to give=
 the<br>
&gt; socket away to the application and tell to the server to stop to commu=
nicate<br>
&gt; with it.<br>
<br>
What socket?<br>
<br>
Data could be being passed by shm, for instance.<br>
<br>
-Rob<br><br></blockquote><div><br></div><div>While shared memory would be q=
uite a bad idea, then why not. I still don&#39;t see why having a way to up=
grade the connection can&#39;t be done.</div><div><br></div><div>Call it I/=
O resource or Socket, the issue is the same. At the end nothing stop the se=
rver to pass the control to the app. If we forget the socket (which is btw =
the simplest design) then the server could stop to control the I/O resource=
 when the application ask it to do it. At some point either a garbage colle=
ction or a basic resource return/claim flow could be used to definitely fre=
e the resource.<br></div><div><br></div><div>The thing behind that is that =
it would allow the WSGI spec to only focus on providing a strict gateway wo=
rkflow without forcing the application to adopt a concurrency model aync or=
 not.</div><div><br></div><div>- benoit.=C2=A0</div></div></div>

--001a113f16da3ee8960529c5ec62--

--===============5646074409608240776==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============5646074409608240776==--