Re: Implementing socket-io for Stackless

--===============0799265233483189594==
Content-Type: multipart/alternative; boundary=001a11c20324db7e4e051087a2bc

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

Ah,
When I left CCP I got permission to take StacklessIO and make it open
source.  In my last months there, I had been working on a Mac OSX version
of it.
This would port very easily to linux, with some minor work (mac OSX has a
built in thread pool library that linux doesn=C2=B4t, and threads are neces=
sary
for some operations that don't have async versions)
Anyway,  I was looking through my source for this stuff and couldn't find
it, I need to get it from there...

In the end, it is all about how you turn your asynchronous api that the OS
provides you with, into a syncronous one for stackless.  The approach is
different based on the type of API.
For windows, the api is completion based.  You get a notification when
something is done.
On linux, it is retry-based, you are invited to invite a non-blocking
operation when it is deemed likely to succeed.

It turns out that the linux approach is much easier to implement.  The
windows version was full of all kinds of boilerplate and stuff, mostly
because the "outstanding" requests need so much luggage with them while in
flight (return buffers, etc).

The macos version of stacklessio performed pretty well.  I will make this
public, but the outline I employed in stacklessio was this:

1) there was a central event queue serviced by the main thread.  This was
implemented in C and we wold deposit there callbacks that the main thread
should run.
2) a socket request would first try to, e.g. recv().  if it got
EWOULDBLOCK, it would create a "read request", mark the socket for being
watched by someone using select (or equivalent) and then go to sleep, using
a channel-receive on the read request.

3) A worker thread would monitor the sockets marked for IO and their
associated "request" objects.  If the socket is marked as readable, it
would then try reading from it.  If it succeeded, it would mark that
request complete by putting it into the IO event queue, and waking up the
main thread if it was sleepeing, waiting for IO.

4) the main thread would wake up, look at the io queue, see a complete
request there, call its callback, the callback would call channel-send on
the object, and the original stackless reader would wake up.


There are a lot of corner cases and details.
The whole thing was implemented in C++ to maintain object lifetimes and for
other niceties.

The important thing for any stackless application, or an IO driven
application like this, is that there be only one Event queue, that the main
thread services.  It has to bee application wide.
This is why I was so optimistic about Guido's Tulip proposal, that it would
give us an application wide event loop that different frameworks could all
use cooperatively.
Unfortunately, it turned out to be yet another proprietary socket io
mechanism....

K

On 27 February 2015 at 16:16, Andrew Francis <andrewfr_ice-/[email protected]> wrote=
:

> Hi Folks:
>
> Pycon 2015 is coming soon. Lately I have been doing work with node.js. I
> am not fond of node.js. I have looked at the socket-io protocol. I am
> wondering about two things:
>
> 1) Is there any advice about implementing socket-io?
> 2) What does a Stackless Python friend socket-io implementation look like=
?
> I have looked at Go socket-io implementations and they look like Javascri=
pt.
>
> Cheers,
> Andrew
>
> _______________________________________________
> Stackless mailing list
> [email protected]
> http://www.stackless.com/mailman/listinfo/stackless
>

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

<div dir=3D"ltr">Ah,<div>When I left CCP I got permission to take Stackless=
IO and make it open source.=C2=A0 In my last months there, I had been worki=
ng on a Mac OSX version of it.</div><div>This would port very easily to lin=
ux, with some minor work (mac OSX has a built in thread pool library that l=
inux doesn=C2=B4t, and threads are necessary for some operations that don&#=
39;t have async versions)</div><div>Anyway, =C2=A0I was looking through my =
source for this stuff and couldn&#39;t find it, I need to get it from there=
...</div><div><br></div><div>In the end, it is all about how you turn your =
asynchronous api that the OS provides you with, into a syncronous one for s=
tackless.=C2=A0 The approach is different based on the type of API.</div><d=
iv>For windows, the api is completion based.=C2=A0 You get a notification w=
hen something is done.</div><div>On linux, it is retry-based, you are invit=
ed to invite a non-blocking operation when it is deemed likely to succeed.<=
/div><div><br></div><div>It turns out that the linux approach is much easie=
r to implement.=C2=A0 The windows version was full of all kinds of boilerpl=
ate and stuff, mostly because the &quot;outstanding&quot; requests need so =
much luggage with them while in flight (return buffers, etc).</div><div><br=
></div><div>The macos version of stacklessio performed pretty well.=C2=A0 I=
 will make this public, but the outline I employed in stacklessio was this:=
</div><div><br></div><div>1) there was a central event queue serviced by th=
e main thread.=C2=A0 This was implemented in C and we wold deposit there ca=
llbacks that the main thread should run.</div><div>2) a socket request woul=
d first try to, e.g. recv(). =C2=A0if it got EWOULDBLOCK, it would create a=
 &quot;read request&quot;, mark the socket for being watched by someone usi=
ng select (or equivalent) and then go to sleep, using a channel-receive on =
the read request.</div><div><br></div><div>3) A worker thread would monitor=
 the sockets marked for IO and their associated &quot;request&quot; objects=
.=C2=A0 If the socket is marked as readable, it would then try reading from=
 it.=C2=A0 If it succeeded, it would mark that request complete by putting =
it into the IO event queue, and waking up the main thread if it was sleepei=
ng, waiting for IO.</div><div><br></div><div>4) the main thread would wake =
up, look at the io queue, see a complete request there, call its callback, =
the callback would call channel-send on the object, and the original stackl=
ess reader would wake up.</div><div><br></div><div><br></div><div>There are=
 a lot of corner cases and details.</div><div>The whole thing was implement=
ed in C++ to maintain object lifetimes and for other niceties.</div><div><b=
r></div><div>The important thing for any stackless application, or an IO dr=
iven application like this, is that there be only one Event queue, that the=
 main thread services.=C2=A0 It has to bee application wide.</div><div>This=
 is why I was so optimistic about Guido&#39;s Tulip proposal, that it would=
 give us an application wide event loop that different frameworks could all=
 use cooperatively.</div><div>Unfortunately, it turned out to be yet anothe=
r proprietary socket io mechanism....</div><div><br></div><div>K</div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 27 February 2=
015 at 16:16, Andrew Francis <span dir=3D"ltr">&lt;<a href=3D"mailto:andrew=
fr_ice-/[email protected]" target=3D"_blank">andrewfr_ice-/[email protected]</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div><div style=3D"color:#000;backg=
round-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,L=
ucida Grande,sans-serif;font-size:12px"><div dir=3D"ltr">Hi Folks:</div><di=
v dir=3D"ltr"><br></div><div dir=3D"ltr">Pycon 2015 is coming soon. Lately =
I have been doing work with node.js. I am not fond of node.js. I have looke=
d at the socket-io protocol. I am wondering about two things:</div><div dir=
=3D"ltr"><br></div><div dir=3D"ltr">1) Is there any advice about implementi=
ng socket-io?</div><div dir=3D"ltr">2) What does a Stackless Python friend =
socket-io implementation look like? I have looked at Go socket-io implement=
ations and they look like Javascript.</div><div dir=3D"ltr"><br></div><div =
dir=3D"ltr">Cheers,</div><div dir=3D"ltr">Andrew</div></div></div><br>_____=
__________________________________________<br>
Stackless mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"http://www.stackless.com/mailman/listinfo/stackless" target=3D"_=
blank">http://www.stackless.com/mailman/listinfo/stackless</a><br></blockqu=
ote></div><br></div>

--001a11c20324db7e4e051087a2bc--


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

_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
--===============0799265233483189594==--