From: David N. <dno...@ya...> - 2006-08-27 00:44:51
|
CGI scripts and function calls can currently cause misterhouse to pause, since they run in the main loop. As Matt said, only the process that sends the response back is forked. There used to be a way to keep a http request socket open until a voice command finished a forked process, but I can't find an example of that. Maybe it's been abandoned? David ----- Original Message ----- From: "Mike Wiebke" <mw...@ya...> To: "The main list for the MisterHouse home automation program" <mis...@li...> Sent: Saturday, August 26, 2006 11:49 AM Subject: Re: [mh] SOAP Capabilities added > Matt, > > After a sufficient amount of coffee this morning I started looking into > this a little more and realized that http_server was single threaded and > just forked certain processes. What you are saying makes perfect sense to > me now. > > I think the three phase solution will probably be the best. > WebServices.pm can just fork off a long running process and return > immediately and possibly pass back some type of url or ticket that the > client can use to check back with later to check on the status of the > process. I think this is what David was suggesting, and it makes sense > now that I realize we can't block until the request is done. As you said > this will only work for processes that can run externally to mh since it > cannot affect the internal mh variables. > > I think for now we will just have to live with the blocking and find ways > to work around it for the occasional long running process. I wonder if > this will be neccessary for the log reading / parsing functionality that > Gregg was going to work on? I suppose it will depend a great deal on how > large the log files become. > > Thanks for clueing me in on this, > > Mike W. > > ----- Original Message ---- > From: Matthew Williams <mat...@us...> > To: Mike Wiebke <mw...@ya...>; The main list for the MisterHouse home > automation program <mis...@li...> > Sent: Saturday, August 26, 2006 11:12:47 AM > Subject: Re: [mh] SOAP Capabilities added > > Mike Wiebke wrote: >> So it would appear that I have a pretty major design flaw in the SOAP >> implementation. Somehow I need to create a new thread for a request when >> it comes in so that misterhouse can continue running during a long >> request. How does the http_server handle this? I would think that I >> actually need to create a new thread when the socket connection is >> accepted but I am currently letting http_server handle that part. Is >> there a way to make http_server create a new thread for a socket? Do any >> of you perl / misterhouse gurus out there have any suggestions as to >> where I should start on this? >> > > Mike, > > Interesting problem. I think the problem really boils down to the fact > that > misterhouse is a single thread/process program. It can only do one thing > at > a time and can only make use of forks / threads in very specific > circumstances. Put simply, if an action has the potential to change the > internal state of mh, a fork won't work. > > I think that you are going to have to simply live with the fact that a > SOAP > request will block other requests. It is no different from any other > misterhouse action in this respect. We do currently fork off "external" > actions like pulling down external web pages for parsing or generating > graphs from rrd databases. > > Maybe this is the solution to your problem - find out which actions take a > long time and figure out a way for misterhouse to split the action into 3 > phases, similar to how we do it for other things. phase 1 - respond > immediately with "ok, going to do it", phase 2 - actually do it in a fork, > phase 3 - "here's the answer" once the fork completes. Remember though, > only external stuff can be successfully forked, anything changing internal > mh states will cause unexpected results to say the least. > > I have been trying to think of ways to improve this for you, but although > you could spawn a fork for each connection, there is always the problem > that > mh itself will block until it's finished putting together its response. > > As misterhouse is asked to do more and more, I believe that this single > thread/process architecture is going to become a potential Achilles heel. > Prehaps multiple processes / threads will be part of mh 3.0? > > By the way, I hope that I am totally wrong with my analysis! :-) It would > be great if someone can figure out a way to allow misterhouse to do more > than one thing at the same time without a major overhaul. > > Matt > > P.S. http_server does already use forks, but only once the results of the > request have been put together. The idea is that over a slow connection, > sending a large block of data back to the client could take a long time > and > cause a pause. Mh still blocks while the response data is being put > together. > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > |