Re: How to monitor long-running fork in Skunkweb?

On Tue, Mar 08, 2005 at 01:00:21PM -0500, [email protected] wrote:
> I would like to kick off a long-running process and allow
> the user to monitor its progress in real time.  On Webware
> I have the long-running process in one thread placing status
> information into the session, where the monitor thread can
> periodically read the status information from the session
> and display it to the user.
> 
> Since Webware is threaded and not forked, I placed a mutex
> around reading and writing session information so the two
> threads do not clobber each other.  Does anyone know how
> such a clobber-preventing measure would work in Skunkweb,
> where two forks access the session data in this way?

Here we go, Pandora's Sessions....

In the general case, SkunkWeb sessions don't deal particularly well or
at all with the case of multiple processes accessing and mutating the
same session at the same time.  If that happens, one process can
clobber the other's updates.  The session isn't in shared memory (at
least not in the distributed session implementations; you could write
one that was, I suppose) and you can't update another process's view
of what the session data is once it has loaded it.  Basically, in
SkunkWeb, sessions aren't a technique for sending messages to another
concurrent process; they are solely for persisting data for future
requests which are assumed not to be liable to make concurrent
writes.  That may well be a dubious assumption.

There are alternatives to sessions for this.  You could let the
progress data be pulled when requested, say, from a unix socket; or
write it to its own file that isn't going to be used for any other
purpose, etc.  (The address of that socket/file could go into the
session at fork time, as a function of the child pid.)  This
completely avoids the lost update problem, and it is what I'd prefer.

If you were to use a session, it may be that losing an update wouldn't
be so terrible insofar as the progress data is concerned; another
update will come along in N seconds anyway, and I assume that the
absolute accuracy of the progress information isn't important.
However, if the user is doing something else which is getting stored
in the session, that data, which presumably you don't want to lose,
could get clobbered.   

I admit to not having ever used sessions in SkunkWeb except for simple
tests; I've always hand-rolled my own persistence mechanisms, which is
more my style.  But that is no excuse; SkunkWeb's sessions are really
very naive, which is seeming less charming than it once did.  It may
be that an entirely new implementation is needed to properly address
these problems.

js



-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCLoTBuqamFyFXXLIRApDVAKCQ4bbVvwfBh43vWD0StYN3yM6bRQCffMdc
eii4eWmwSY+aQYepuxQ64cE=
=n//R
-----END PGP SIGNATURE-----