On May 19, 5:41 pm, amoygard <amoyg...@gmail.com> wrote: > Thanks for the answer - I was aware that I don't have to do this to > handle ajax requests in general. The application I'm building needs to > send and receive a sequence of messages from the client in a specific > order, so I thought it would be easier to handle it in one thread/ > process. It is however probably better to do it statelessly as you > say, so I'll probably have to rewrite the code somewhat. > > Out of curiosity though, what is the right way to start a subprocess > in web2py?
On Wed, May 19, 2010 at 10:41 PM, amoygard <amoyg...@gmail.com> wrote: Thanks for the answer - I was aware that I don't have to do this to handle ajax requests in general. The application I'm building needs to send and receive a sequence of messages from the client in a specific order, so I thought it would be easier to handle it in one thread/ process. It is however probably better to do it statelessly as you say, so I'll probably have to rewrite the code somewhat. Out of curiosity though, what is the right way to start a subprocess in web2py? In general, you don't - unless you have a long-running process that is divorced from http requests coming in from the network (for long running processes, there is a sort of "cron" facility). In a hosting environment, you have apache/wsgi (for example) running a wsgi-thred that is web2py - that (main and the stuff in gluon) is your long-running process (er, thread). To restart web2py, with wsgi, you would do what is normal (touch a file) to cause apache to re-start that wsgi thread. Other than from something like a terminal on your server, you do not do this (it would not be uncommon for this to run year-long without a restart). Within web2py, you have a number of threads: db connection pools, and application threads; again, these respond to requests, and are spawned off by web2py (not you) - Massimo, or someone who has dug into this recently could comment on how that works - but frankly, that is not important. Your web app _is_ running in a stateless environment: web requests. You have a way to "capture" some state on your own: sessions. I only know of one framework that uses the tasklet facility of stackless, and that's nagare --- it seems to use a tasklet to wait for a return so that you seem to generate a view inline in your code. In web2py, your (for example) default/index() controller is typically called multiple times, and decides (though it's mostly masked from you) through logic if it's an initial request, or a response --- i.e., when you call something with a form, there is a check by means of form.accepts() to see if the response variables are populated, and (somewhat behind the scenes) all the stacks of appropriate validators are run. This is why you see things like form.accepts() success or fail conditions, and fall thru if neither (i.e. not a response yet). So - in general, you do not start subprocesses - with the exception of cron. See http://www.web2py.com/book/default/section/4/17 - Yarko > > On 19 Mai, 22:00, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > > > On May 19, 2:14 pm, amoygard <amoyg...@gmail.com> wrote: > > > > Hi, > > > > I'm pretty new to web2py and web application frameworks. I'm trying to > > > create a new background process in controller to handle incoming ajax > > > data from a user. > > > You are trying to do too much: remember: the web is "stateless" --- > > when _anything_ comes in from a client that gets directed to your URL, > > (this is just an example flow, so you can get the general idea): > > > - somewhere, a DNS server replaces the URI name with a destination > > address; > > - the destination server (let's say apache) tries to sort out, and > > direct to the correct app (in this case, web2py); > > - web2py's main() parses the path part of the URI to decide how to > > route internally > > - if it finds a matching app/controller, main() will set up the > > execution environment to prepare the call: > > - i.e., your models are "executed" so that the table definitions, > > etc. are all in the environment, and then your controller file > > - the function in your controller is called with this execution > > environment (this is the thread that you are trying to make, and > > should not bother) > > > The controller function does it's stuff with the request, and returns > > (to main()) the response - sometimes nothing, sometimes a dict. of > > stuff; > > Main takes the return values from the controller, and processes > > appropriately, most often getting the view, parsing the template, > > creating the resulting view, and sending it back to the client. > > > When an ajax call is made, you can see an example > > athttp://www.web2py.com/book/default/section/10/3, and explanation of > > what this does. > > > The general point: you call a controller with a request (even in the > > case of an ajax call); > > The response goes back to the caller. > > > Lots of stuff happens for you - you don't need to write the entire web > > server underpinnings; just worry about the logic you want to > > implement so server and client can converse / exchange information. > > > Hope this helps. > > > Regards, > > - Yarko > > > > I'm using the module multiprocessing for this. > > > However, when I start the new process, a new instance of web2py server > > > is started? I'm assuming this has something to do with forking (which > > > I don't know much about). Is there an easy workaround? Or should I > > > preferrably do this some other way, for instance with threads? > > > > Code is as follows (controller calls function 'someinit' in a module > > > in module-folder): > > > > def tekstpr(mstring,conn): > > > print mstring > > > conn.send("hello") > > > > def someinit(userid): > > > from multiprocessing import Pipe, Process > > > parent_conn, child_conn = Pipe() > > > p = Process(target=tekstpr,args=("I'm alive!",child_conn)) > > > session.procpipe = parent_conn > > > p.start() > > > session.procpipe.poll(300) > > > return session.procpipe.recv()
