Re: Web Site Process Bus

Phillip J. Eby wrote:
> At 02:41 PM 6/25/2007 -0700, Robert Brewer wrote:
> >Phillip J. Eby wrote:
> > > Meanwhile, if you get a start call, you must
be starting, 
> right?  So
> > > why worry about the state?  It'd be simpler
to just use
> > > "before/during/after" messages the
way Twisted does.  Your "block"
> > > example could be replaced by waiting for the
"after" 
> message of the
> > > desired state, for example.
> >
> >I just realized I haven't really explained what
"start" and 
> "stop" mean.
> >I think you might expect it to mean "beginning
of process" 
> and "exit the
> >process". But instead, I'm envisioning a FSM
that has an "idle" state
> >in-between process init/exit and "server"
start/stop, so 
> that, without
> >restarting the process, you can stop and restart
(un/bind the socket,
> >etc) the server components. This should also
facilitate a 
> daemon parent
> >process having a single site Bus and
starting/stopping child 
> processes
> >that contain the WSGI app and server components, if
that's 
> the way you
> >want to compose your site.
> 
> Now I'm really confused.  What is the idle state
*for*?

One concrete use case could be a test suite that swaps out
applications
between tests without exiting the entire process. But there
are other
situations where it's useful. The startup script might need
a chance to
run mandatory code in-between stop and exit, or a debugger
might stop a
live server (stop accepting connections), run a debug
session, fix the
problem, then start up again.

> This seems to imply that you need these states to exist
for
> distinct components in a single process -- which would
be a
> finer-grained sort of "bus" than has been
discussed at this
> point, at least as far as I understand it.

That's not what I had in mind, but I wouldn't be opposed to
it.


Robert Brewer
System Architect
Amor Ministries
fumanchuamor.org
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

All,

>> Now I'm really confused.  What is the idle state
*for*?
> 
> One concrete use case could be a test suite ...

Is this also where Joe's comment in Dallas fits, namely, the
case 
where you want to hold open a socket while restarting a
child 
process so as not to drop connections?



chad
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

On Monday 25 June 2007 20:32:38 Chad Whitacre wrote:
> All,
>
> >> Now I'm really confused.  What is the idle
state *for*?
> >
> > One concrete use case could be a test suite ...
>
> Is this also where Joe's comment in Dallas fits,
namely, the case
> where you want to hold open a socket while restarting a
child
> process so as not to drop connections?

It's not so much a desire to not drop connections as to keep
the socket file 
descriptor during a restart to prevent an asynchronous
kernel call 
(socket.close()) from preventing your new process from
reopening that socket.  
The frequent work around is to insert an arbitrary sleeps or
loops on the 
socket.bind call, but I store the file descriptor as an
environment variable 
and reconnect to the existing socket after the exec call. 
This is a problem 
on Linux at least, and probably all POSIX systems.  Having
the kernel queue 
up connections is an added bonus.

I do think this is a good example of what the IDLE state
could be used for.

-- 
Joseph Tate
Software Engineer
rPath Inc.
http://www.rpath.com/r
builder/
(919) 851-3984 x2106
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com