On 2 Apr 2012, at 15:37, Simon wrote: > On 2 April 2012 14:27, Stuart Dallas <stuart@xxxxxxxx> wrote: >> On 2 Apr 2012, at 14:12, Simon wrote: >> >> > Thanks Maciek >> > >> > On 2 April 2012 10:37, Maciek Sokolewicz <maciek.sokolewicz@xxxxxxxxx>wrote: >> > >> >> On 02-04-2012 10:12, Simon wrote: >> >> >> >>> Thanks Simon. you got my hopes up there for a second. >> >>> >> >>> From the php docs page: >> >>> >> >>> Critics further argue that it is pointless to use a Singleton in a Shared >> >>>> >> >>> Nothing Architecture like PHP where objects are unique>within the Request >> >>> only anyways. >> >>> >> >>> I want the the singleton class to be global to the entire application (ie >> >>> shared "by reference" across all requests). I'd agree with the above >> >>> critics that if you have to instantiate your singleton for each request, >> >>> it's rather pointless. >> >>> >> >>> Well, that's simply not possible due to the "shared nothing paradigm". >> >> If you want to share, you need to either share it via another medium (such >> >> as a database, as has been suggested a dozen times already) or switch to a >> >> different language. >> > >> > >> > >> >> PHP is based on this paradigm, and you should not expect of it to violate >> >> it just because you want to do things a certain way, which is not the PHP >> >> way. >> >> >> > >> > The existence of memcached, shm and apc_fetch tell me that PHP already >> > accepts the need for sharing data between processes. All I'm arguing for is >> > the ability to share the data by reference rather than by copy. >> >> >> As already mentioned several times the closest you will get is shared memory (as used by APC), but you can't access that by reference because shared read/write resources need controlled access for stability. > > I know. I understand that (and the issues with locking that might arise if truly shared memory was available). > >> I can't find any material that explains how the .net framework implements application variables. You mentioned earlier that you *know* that when you access them you do so by reference. Do you have a source for this knowledge or is it some sort of sixth sense? > > Source: 10+ years as an ASP and ASP.NET developer. Wow. As knowledge goes that's up there with "I believe it therefore it is." > Having looked for documentation, I agree, it's utterly terrible. It's as if even Microsoft themselves don't fully understand the advantages that application variables give them over the competition. (Though they're hardly likely to be forthcoming about helping others implement similar features). > > Here's some stuff I did find: > > http://www.codeproject.com/Articles/87316/A-walkthrough-to-Application-State#e > This article explains basically how application variables work. It doesn't specifically mention passing by reference but it discusses thread safety at some length so you might infer that implies passing by reference. "can cause performance overhead if it is heavy" And you want to store petabytes of data in there. Smart. Anyway, that page says nothing about whether it's accessed by reference. It implies that writes are atomic, which in turn implies that there is something in the background controlling write access to the data. As for reading the data being done via references there is nothing in that article to suggest that. > http://msdn.microsoft.com/en-us/library/ff650849.aspx > Here is a more technical discussion about the singleton class is implemented in .NET. Application variables are provided by an instance of a singleton class (the HttpApplication class). Looks no different to the way you'd implement a singleton in PHP (as expected - as a concept it doesn't generally change between languages). Just because the HttpApplication class is a singleton doesn't mean that when you request data from it you get it by reference. > http://stackoverflow.com/questions/1132373/do-asp-net-application-variables-pass-by-reference-or-value > Stack overflow question from someone actually wanting to get a *copy* of an application variable rather than a reference. According to that page scalar values are returned by value, objects are returned as a copy of the reference. Based on that, it would appear that you are correct as far as objects are concerned. However, the advice given on several pages I've found, including at least one that you've specified, is to use application variables lightly and sparingly. It's not something that should be used for petabytes of data, mainly because it's all STORED IN MEMORY. > So, if you read enough of this stuff, you'll find out that a .NET website (an IIS application in MS parlance) runs in a multi-threaded single process. Application variables (and singleton classes) are shared by reference between all threads. It is possible to run an IIS application over multiple processes (to take advantage of multiple processors / server farms for example) but then the Application variables are not shared at all. (This is then pretty comparable to the situation with node.js except that node is not multi-threaded) Single process. Yes. Precisely. PHP *DOES NOT WORK LIKE THIS* and probably never will, therefore it's not comparable. And why do you insist on comparing anything with Node.js? Node is specifically single-process and, as far as the JS developer is concerned, single-threaded. Node can't share data across processes in the same way PHP can't. They're also completely different architectures... Node implements the web server within the Node process, PHP does not. It's not logical to say that an apple should be like an orange. I don't understand why we're still talking about this. The architecture of PHP does not make sharing data by reference possible, regardless of whether that's how ASP.net works. It's irrelevant and frankly I couldn't care less (which I think I've mentioned before). I used to use ASP and ASP.net, so I am familiar with application variables, but I've never missed them since moving on to other technologies. This could be related to the fact that when I moved away from ASP I also moved on to far higher levels of traffic than I had ever dealt with before. You said that memcached was slow compared to the .net application variables; of this I have no doubt. But again, that's irrelevant. The .net application variables cannot scale beyond a single process; memcached can comfortably scale to many thousands of servers and beyond. I use a combination of generated PHP files (for things that don't change one the app is running), memcached (for things that do), and many other technologies to build web applications that serve many millions of users every day, and I have no complaints. Per-process (or even per-server) application variables never cross my mind - they just don't provide any significant benefit. If you want PHP to work the way .net works, modify PHP yourself or pay someone to do it for you, because I practically guarantee that you'll find next to no support for moving away from the shared-nothing architecture of the PHP core. Alternatively... stick to ASP.net. I'm done. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
