From: Erik J. <er...@sg...> - 2005-10-10 20:18:06
|
> Yes, I understand that. But I wonder if it is a feature that is actually used. > If you want to track a collection of tasks as a job, it seems like would The features of job you wish to remove are used by SGI itself by our opensource but not-actively-pushed array sessions kernel module. It's used by SGI's MPI implementation. Some features were added to Job based on feedback in part from customers but I can't prove they're using the features. In any case, we would still want the ability to throw away a job without waiting for processes to die. I'm not sure that's easily possible without locking that list. I can probably work around it some how. It also seems like the type of thing other kernel modules may be interested in doing. It seems like it is reasonable to believe that kernel modules that "do things with tasks" may be interested in more than just "current" or it's child. Job is, why not others? > create an application launcher, put the launcher inside a job container, > then launch the application from launcher. That assumes one specific use of job containers. What if an administrator wanted to contain all users running a specific type of process and group them to be signaled and tracked as one? That doesn't seem unreasonable and it's part of why Job has these features today. For example, the admin might want to put all the weather model simulations from all users in to a job so she can signal them or track them for accounting. I'm still interested in this question: Why are we avoiding locks? semaphore locks are simple to implement, easy to read in the code, and I've shown don't cost much in terms of fork time with pnotify. Am I wrong here? Is it because we're using more memory per task? If we're concerned about fork times and the tests I've run aren't adequate, I'd like the chance to try other tests. Erik |