One thing I find myself doing more often than I'd like is waiting for
things to finish. This isn't because Squeak is slow, it is because I'm
into analyzing the whole image for this or that, and because running
code in the background isn't quite as easy as should be. Forking is
easy, but then it's harder to 
* inspect the results (need to assign to a variable and do it after it
has finished)
* know when it's finished
* know how much processor time it ate.

IIUC, what you're proposing would make the last much easier, which would
certainly be nice.

Daniel

John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> Actually that reminded me, a year or more back I had a changeset that  
> added some instance variables to Process that allowed you
> to assign an identifier, but more importantly in  
> Interpreter>>transferTo: it had logic to track how many clock ms that  
> the process had
> executed for. Thus you could see exactly how much wall clock time a  
> process got, versus the current method of guessing.
> 
> I also consider collecting say disk interaction, and network  
> interaction on a process basis, but no-one seems interested. Think of  
> the Unix top command.
> 
> So let me ask is there interest in the clock time data?
> 
> > if you look at
> > Interpreter>>transferTo: aProc
> > 	"Record a process to be awoken on the next interpreter cycle.
> > is where process switching occurs.
> --
> ======================================================================== 
> ===
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ======================================================================== 
> ===