http://www.perlmonks.org?node_id=11148152


in reply to having a container on perl VMs is good ?

It is true that you can only get cross-thread global variables using XS because Perl does not have a synchronization API to make sure only one thread modifies data at a time. C/++ does have this feature, so you can add it to Perl using XS modules.

(Edit: I stand corrected, Perl does! threads::shared is a core perl module)

Now, you say it would give perl more power for multi-processing if Perl did have this, but you need to make a stronger argument to convince us. To start with, many of us do not even use perl threads in the first place, and may even disable the feature in our perl interpreter to make it run faster. This is not because we aren't familiar with the idea (I did a lot of Java back in college) but because we have found other ways to solve our problems using perl.

For shared structured data, most of us use a database. There are many databases to choose from, too. You can of course run Postgres and create a table with a 'json' column, and write arbitrary data to it, or you can use a database-file like LMDB_File or SDBM, SQLite etc. In these cases perl memory-maps the file data and serializes and deserializes on each read/write. If you need locking, you can implement it with flock.

For shared flat data, you can just File::Map it into each process or thread, and have high-speed un-synchronized access. This is most useful with large static data that doesn't need synchronized anyway.

For the few types of problems where people really do want this, they probably also want more speed than plain perl. The XS modules give you a lot of speed in addition to extra threading features.

While it used to be common for people to implement high-speed transactional behavior inside of a single process, I just haven't needed to do that in the last 15 years that I've been using perl. Almost every modern application needs the potential to scale up beyond one process on one host, so I pretty much start every project assuming I will use some type of database.

Maybe you can describe the problem you're trying to solve that would benefit from tight single-process relay of data structures between threads?

  • Comment on Re: having a container on perl VMs is good ?

Replies are listed 'Best First'.
Re^2: having a container on perl VMs is good ?
by Corion (Patriarch) on Nov 12, 2022 at 06:45 UTC

    Not to detract from your points, threads::shared has synchronization primitives and also ensures that a shared variable is written to by only one thread at a time.

    But IMO when you start using / needing these, something went wrong in the overall design already. I prefer to structure my thread code around Thread::Queue, which changes the design to something message-based and which is far easier to reason about than variables that get updated by multiple threads.