Hi Kristjan:
Thanks for the reply. I will take another look at stackless-io when it becomes
available. For now, I guess my concerns revolve around starting. I am starting
to look at the socket-io protocol. I am wondering if there are any websocket
Stackless Pythonimplementations. I should look at how gEvent does things.
Done right, I think Stackless can provide a more developer-friendly
implementation of Socket-io than Node.js can.
Cheers,Andrew
On Thursday, March 5, 2015 6:00 AM, "[email protected]"
<[email protected]> wrote:
Send Stackless mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.stackless.com/mailman/listinfo/stackless
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Stackless digest..."
Today's Topics:
1. Re: Implementing socket-io for Stackless (Kristj?n Valur J?nsson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 5 Mar 2015 10:00:22 +0000
From: Kristj?n Valur J?nsson <[email protected]>
To: Andrew Francis <[email protected]>, The Stackless Python
Mailing List <[email protected]>
Subject: Re: [Stackless] Implementing socket-io for Stackless
Message-ID:
<CAP8kY6bsTAvyhY+aDPsbzdt0dcimo1kAhC3=Ekptfs=_r8GU=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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?t, and threads are necessary
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 <[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 Javascript.
>
> Cheers,
> Andrew
>
> _______________________________________________
> Stackless mailing list
> [email protected]
> http://www.stackless.com/mailman/listinfo/stackless
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.stackless.com/pipermail/stackless/attachments/20150305/18f03f15/attachment-0001.html>
------------------------------
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
End of Stackless Digest, Vol 133, Issue 1
*****************************************
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
