An introduction to asynchronous Python

Posted Jun 29, 2017 16:58 UTC (Thu) by zlynx (guest, #2285)
In reply to: An introduction to asynchronous Python by willy
Parent article: An introduction to asynchronous Python

Interpreters like Perl and Python which use reference counts are terrible about data sharing. Even if a variable is read-only the reference count bumping as it is passed around unshares the pages.
I noticed this on SpamAssassin on 256 MB boxes years ago. It used an initialize and fork model, obviously copied from a C application, perhaps Apache. It should have been very memory efficient. However, as soon as a SA worker began to work, it's memory quickly unshared and started to overload the box.

And of course there are C++ apps using shared_ptr and std::string which do just as badly at this.

An introduction to asynchronous Python

Posted Jun 29, 2017 19:51 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Interesting point. This suggests that if you are going to use reference counting, the counts should be stored separately from the object, in some kind of global array or global lookup of address to count. Then they will be in their own pages, while the objects themselves stay mostly read-only.

An introduction to asynchronous Python

Posted Jun 29, 2017 22:49 UTC (Thu) by excors (subscriber, #95769) [Link]

I think std::shared_ptr can sort of do this already - you can pass the constructor a raw pointer (allocated however you want) plus an allocator object that will be used for internal allocations (i.e. refcount storage etc), and you could make that allocator use a separate pool to keep all the refcounts together. Then wrap it all in a custom type so users don't have to think about it.

(Apparently constructing a shared_ptr via std::make_shared is special - that does a single allocation to contain both the refcount and the object, which is usually a good idea, but in this case you'd need to implement it differently, which should be easy enough.)