On 13 February 2010 07:28, till amon <[email protected]> wrote: > Thanks for your interest and of course i don't mind. > > Atm i'm doing something like a chatroom-on-steroids, mainly to get a > grasp on the various web technologies around. > > So if i have one process that propagates update information around > ( people join, leave , post ... ) > there is basicaly one thread for each user, that accepts an incoming > ajaxy request and then sleeps until there is any state change to send > back. > > So if i had a second process handling file uploads i would like to > notify the first process upon completion of the upload with as little > overhead as possible, which would then trigger all those sleeping > threads to send the update information.
May be too heavy, but use an XML-RPC call to call back from one process to the other. BTW, having one thread per user itself may not be a good idea as it will not scale very well. You should look at event driven systems instead. There are various Python web servers designed specifically for asynchronous model which can handle high concurrency without threads. Have a look at Tornado as the current poster child. Graham > ( don't know. can databases send out asynchronus events these > days ? ) > > ... erm its not really about whether it makes a lot of sense. more > about testing how much responsiveness can be squeezed out of this > xmlhttprequest everyone seems so crazy about these days, and which > design to use for that. > > Therefor the rather aimless question for direction. > I'm not that firm with the web yet, any hint would be appreciated. > > cheers > > On Feb 12, 8:35 pm, Rishi Ramraj <[email protected]> wrote: >> From what I understand, state information for web apps is usually >> stored in databases. What are you trying to do, if you don't mind me >> asking? >> >> On Feb 12, 10:09 am, till amon <[email protected]> wrote: >> >> > Hello all, >> > and apologies upfront for going to be vague. >> >> > i'm toying with mod_wsgi for a couple of days now and still am >> > somewhat struck when it comes to threading semantics - especially how >> > to share state between processes. >> >> > the current setup is like this : >> > WSGIDaemonProcess daemon_group processes=1 threads=15 >> >> > Which is working fine as long as there is only one process. >> > now to the vague part : if one wants to have other processes serving >> > different scripts , what would be the cleanest way to share state >> > among them if responsiveness was the main concern ? >> >> > (starting a 16th thread to wait for a unix pipe or socket does not >> > seem to work - by design i guess ? ) > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
