> -----Original Message----- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Sunday, December 12, 2004 11:33 PM > To: CF-Talk > Subject: RE: CF vs ASP.NET! GET YOUR FRESH POPCORRRRN!! > > I think you're a bit off...
I think that the original poster might be confusing two separate things here: asynchronous calls and thread pooling. CF has been doing thread pooling since it became truly multi-threaded in CF 3 or 4 (I forget which... but I think it was 3). All this means is that a certain number of threads is set aside for handling requests (the default is 10). When a request comes in it's assigned to a thread from the pool which runs it serially and returns. If all threads are active the request is queued and will be assigned the first available thread. As an aside the number of threads is only important in relation to your application. It should be clear that all active threads actually share the resources of the box. So, for example, if your application is highly CPU-bound (a calculator of some time or a data processer) then it's generally recommended that fewer threads be created. This means that more requests may have to wait, but that more processor time can be spread amongst the relatively few threads - this ensures that once a request gets a thread it finishes as fast as possible. (Remember that in actual fact the CPU is essentially running in serial - working on a small piece from each thread one after the other, not at the same time. Since thread management can consume significant resources you want to set your thread count low enough where you're not spending more time managing threads than completing your processing.) By the same token if you're threads may spend a lot of idle time - for example waiting for a web server or a database to respond you can up the number of active threads. Since they're only waiting for responses they're not consuming significant resources on their own - so why not allow a lot of them to "put in their orders" and wait instead of just a few? Anyway, that's thread pooling. We've had it forever and so has everything else. But the key point here is that within a thread everything runs in SERIAL - it plods along one after the other. A CF template can't call a database and then output a timer while it's waiting for a response. It must make the call, then wait for the DB to respond and then continue. Asynchronous calls (what Isaac was talking about originally) address this problem. This means simply that a single request can start something, then do something else while the first thing is working. Such processing isn't as necessary in web applications as in client-side applications (for example, think how annoying it would be if you counld't read email at the same time you were fetching new mail?) but can be very useful in certain situations. For example I've got a page that allows the user to fetch a PDF from the server. The page checks security permissions, writes and entry to a metrics log file, then delivers the PDF. In this case, as it is today, you musty get a response from the database to continue to deliver the PDF. But the metrics logging isn't critical to the process (in this case at least) so why should it delay the customer request? With an asynchronous call I could "spawn" a new thread to handle the database entry and then immediately deliver the file. The PDF thread would continue even if the new logging thread failed or was slow for some reason. >From a single request I created two distinct, parallel processes that didn't have to be dependent upon one another. I'm not sure how this will be implemented in BlackStone - Isaac's post was the first I'd heard of it. But it is doable in Java (of course) and it wouldn't be all that hard to create a CFC to kick something like this off in CFMX (several people on this list have already done it I'm sure). If they're going to standardize it in BlackStone, more power to them, but HOW they're going to do it I'm not sure. Will they only support "orphaned" threads (threads which are created and launched but can't communicate back to the parent thread) or will they support a more complete model. As I said the actual practical uses for this kind of thing in a web application aren't all that common (think of the really good CF or ASP applications you've seen - none of them support this - I may be wrong, but I don't think PHP supports it either). So I would bet it will pretty simplistic support, not a full thread management model, but that's just a guess. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - CFDynamics http://www.cfdynamics.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:187327 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
