Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Asynchronous IO in Python

medium.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: The Future of Asynchronous IO in Python

#31

Post by lmm »

Animats wrote: post #17

It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms. OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechan…

> Google protocol buffers help, but don't come with a standard RPC mechanism.

Sounds like you want Thrift.

Re: The Future of Asynchronous IO in Python

#32

Post by lmm »

tailhook wrote: post #29
notastartup wrote: post #4

Do we really need to reinvent the wheels? Microservice, the async craze feels like, we now need to create a single wheel that is made up of many wheels, and spend an enormous time making it look and feel like a single wheel that was working fine, never mind that it serves absolutely no difference to the end user, it will make our next few years interesting because the old way of creating the wheel is boring and unexc…

Well, here is a good article: https://plus.google.com/+RipRowan/posts/eVeouesvaVX It seems that Amazon started using microservices in 2002. Do you think 12 years is not enough to learn on mistakes?

Amazon uses microservices because they need to at their scale. But there are maybe a few dozen companies that operate at that scale. 12 years isn't enough time to learn a lot when there are only a few people doing it, just as in e.g. spaceflight.

Re: The Future of Asynchronous IO in Python

#33

Post by icebraining »

crdoconnor wrote: post #24
plainOldText wrote: post #16

Earlier quoted context omitted.

A system which serves millions of users spans multiple machines. It's much easier to scale and evolve your stack if you're keeping it decoupled. Plus if you use something like nanomsg you can keep the services on the same host, and use something like ipc:// for minimal latency, then just switch the protocol and move the service to a new host with no other changes when it's time to scale up. No matter how good your co…

>A system which serves millions of users spans multiple machines. It's much easier to scale and evolve your stack if you're keeping it decoupled. It can be much harder. Let's say that you have a zipcode address conversion library and you're deciding whether to use it within the web stack (option A) or to create an additional service with a REST API on a separate machine (option B). Microservices! Option A means that…

I don't see why would you need to have a load balancer for the zipcode service; if the service truly scales linearly with the number of application servers, you can simply tie them together 1-on-1 with simple configuration.

Re: The Future of Asynchronous IO in Python

#34

Post by jbergens »

lmm wrote: post #31
Animats wrote: post #17

It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms. OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechan…

> Google protocol buffers help, but don't come with a standard RPC mechanism. Sounds like you want Thrift.

Doesn't Cap-n-proto have some RPC mechanism in it? Might help for some cases.

Re: The Future of Asynchronous IO in Python

#35

Post by lmm »

jbergens wrote: post #34
lmm wrote: post #31

Earlier quoted context omitted.

> Google protocol buffers help, but don't come with a standard RPC mechanism. Sounds like you want Thrift.

Doesn't Cap-n-proto have some RPC mechanism in it? Might help for some cases.

Maybe. RPC is a first-class citizen in thrift, and it's more mature and established than Cap'n Proto (and had better cross-language support last time I checked). But whatever works for your use case.

Re: The Future of Asynchronous IO in Python

#36

Post by wslh »

Animats wrote: post #17

It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms. OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechan…

What do you mean with Windows sort of does ? Windows has good IPC.

Re: The Future of Asynchronous IO in Python

#37

Post by jbergens »

untothebreach wrote: post #11
rubiquity wrote: post #10

Earlier quoted context omitted.

The entire premise of this article is that the author has adopted the microservices disease and is suffering from not having asynchronous IO. You'll never hear an Erlang programmer even talk about microservices because they are a solution to a problem that doesn't exist in Erlang, or any sufficiently concurrent language for that matter[0]. Oh, and microservices clearly create other problems, such as messaging. 0 - I…

a lot of the articles I read about microservices seem to come at them more from an organization point-of-view than a concurrency one. That is, encapsulating the logic for one specific component of a system, both for ease of scaling up only the parts of the system that need to be scaled, as well as for a different way for dev teams to interact with other parts of the system. I'm not saying I agree, but I do understand…

I still don't see how it really helps. For organizational concerns it may be easier to say that a team is responsible for a (micro)service than for a library, but it doesn't have to be easier. If they change their API all users will suffer anyway. It doesn't have to help much with scaling either. If the service/library is the thing that uses most of the cpu it will still help to add more servers with everything on them. Microservices actually may cause bigger lag since the network connections may take time (app calls service 1 which calls service 2 etc). If they all were libraries on the same server the calls would be much faster.

You do get an opportunity to monitor each service easier if they live on separate machines (or just separate processes). If you want that with libraries you need to add monitoring code to all libraries and then collect data from them to see where the bottlenecks are. You might also need to develop new tools to configure things like pool-sizes and cache-sizes for each library. For example saying that you should have 5 threads (or handlers) handling mail-messaging and 20 threads/handlers handling calculations. You might also want to be able to change theese configurations in a live system. I think a lot of applications misses this monitoring and configuration part and then gets into problem because of that. And of course microservices helps with using different languages for different parts, even though most organizations I've seen seem to mandate a specific language anyway.

Re: The Future of Asynchronous IO in Python

#38

Post by xorcist »

wslh wrote: post #36
Animats wrote: post #17

It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms. OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechan…

What do you mean with Windows sort of does ? Windows has good IPC.

It depends on what you mean by IPC I guess. There's a billion and one ways to do it, everything from message passing to shared memory. If you want to do Windows-style IPC on UNIX, wouldn't SYSV IPC suffice? (QNX is of course another beast altogether.)

Re: The Future of Asynchronous IO in Python

#39

Post by kevingadd »

leonardinius wrote: post #23
Animats wrote: post #17

It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms. OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechan…

> Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) Could you please elaborate on Windows part of your statement? What particularly are you referring to?

COM/DCOM have offered a relatively usable solution for interprocess and cross-machine RPC for... quite a while. I used it to do interprocess communication back in the VB6 era (it was built-in), and in fact I did it by accident. I picked the wrong checkbox in the project options, so I ended up with the user interface of my application and the backend literally running in separate processes.

Other than the performance overhead (that I initially chalked up to 'oh, COM is just slow I guess'), the way I finally noticed was when a pointer I passed across the COM boundary wasn't valid (because it was to memory in another process). Whoops! Everything was working perfectly up until that point.

(FWIW, I am pretty sure the invalid pointer thing only happened because I was passing a raw address around - VB6 doesn't have pointer types.)

Plus, since COM provides ways to do source-level and binary compatibility, you can leverage that for your RPC.

I won't call it awesome, but it's quite robust and gets used in many places on Windows.

At a more basic level, you can trivially implement RPC using windows messages, though the security model improvements in 7 and 8 have made this a bit more complicated. There is excellent, straightforward infrastructure for establishing message loops and sending messages - really easy to get right - and it doesn't require your application to have UI. Pretty much any thread can receive and process messages if it wants to.

Re: The Future of Asynchronous IO in Python

#40

Post by xorcist »

> (The GIL) is there for other scripting languages too (Ruby, Perl, Node.js, to name a few)

I don't know about Node, but I know it's perfectly possible to write "proper" multi threaded programs in Perl (and has always been since the version string started reporting support for threads, which should be a good 15 years ago).

It's not terribly relevant to the article (because you normally don't write multi threaded programs in Python), but then why bring it up?

Post reply on HN