in reply to sharing a complex set of objects between httpd processes

The short answer is, you can't do that. There is no way to share Perl objects between processes. There are things like IPC::Shareable that make it look like you can, but they all do the stuff you mentioned (serialization, locking, etc.) behind the scenes and just move objects around between processes.

There are two pieces of good news though. The first is that there are ways of sharing data that are very fast, like IPC::MM and Cache::Mmap, despite all the machinery. The second is that you probably don't need to do this at all. If you create things before the fork in startup.pl, each child process will get a copy. If you need to share data, you have the above-mentioned methods and your RDBMS. If you need to coordinate access to some shared resource, you can do locking in various ways.

If you explain why you think you need a singleton, we might be able to offer more specific advice about what to do.

  • Comment on Re: sharing a complex set of objects between httpd processes

Replies are listed 'Best First'.
Re: Re: sharing a complex set of objects between httpd processes
by thpfft (Chaplain) on Mar 15, 2003 at 03:29 UTC

    Thank you (both): very clear and helpful.

    The short answer is that I may well not need the singleton at all: it came from a quite possibly misguided idea of what would be an elegant and economical way to manage the proliferation of Class::DBI subclasses.

    I'm beginning to see that it's a relic of old bad cgi thinking. The fifty or so require()s involved in loading all the cdbi subclasses made the construction of the factory object seem much heavier than it really is, since all that presumably gets compiled away at the beginning. If I make sure the Template object and DBI handles are being managed sensibly, the difference made by the singleton is probably negligible.

    The one thing that I do need to share out among all the processes - apart from the database classes, which can look after themselves - is a new tied-DB-based inverted index. But that will actually get easier, I think, if I don't try and hang on to the factory object after a request has been processed.

    pardon me thinking out loud: i always find that making a fool of myself in public is the best way to lend urgency to the tired brain :(

[reply]
      You are correct: require() and use() calls are basically free in mod_perl. Not sure what the implications are for the inverted index you mentioned. If it's in an RDBMS, you obviously have no problem. If it's in a dbm, you should consider using MLDBM::Sync for it.
[reply]

In Section Seekers of Perl Wisdom