I have a long-lived multithreaded server process that needs to execute programs and interact with them via Handles. The programs could misbehave, like loop or hang, so I need to limit the real and CPU time they can take. I guess System.Posix.Resource.setResourceLimit sets limits on the current process, so I can't use it in the server process. Is it a good approach to write some utility program for the server to call that does setResourceLimit and executes the programs that could misbehave?
On May 5, 2009, at 04:52 , brian@lorf.org wrote:
I have a long-lived multithreaded server process that needs to execute programs and interact with them via Handles. The programs could misbehave, like loop or hang, so I need to limit the real and CPU time they can take.
I guess System.Posix.Resource.setResourceLimit sets limits on the current process, so I can't use it in the server process. Is it a good approach to write some utility program for the server to call that does setResourceLimit and executes the programs that could misbehave?
An alternative is to forkProcess and have the child setResourceLimit and then executeFile. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
On Tuesday, 05.05.09 at 22:48, Brandon S. Allbery KF8NH wrote:
On May 5, 2009, at 04:52 , brian@lorf.org wrote:
I have a long-lived multithreaded server process that needs to execute programs and interact with them via Handles. The programs could misbehave, like loop or hang, so I need to limit the real and CPU time they can take.
An alternative is to forkProcess and have the child setResourceLimit and then executeFile.
The documentation for forkProcess seems to say that Handle-based I/O won't work in the child process. I need to communicate with the program I'm running via its standard input and output. Does this mean forkProcess is out of the question?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 6, 2009, at 16:18 , brian@lorf.org wrote:
On Tuesday, 05.05.09 at 22:48, Brandon S. Allbery KF8NH wrote:
On May 5, 2009, at 04:52 , brian@lorf.org wrote:
I have a long-lived multithreaded server process that needs to execute programs and interact with them via Handles. The programs could misbehave, like loop or hang, so I need to limit the real and CPU time they can take.
An alternative is to forkProcess and have the child setResourceLimit and then executeFile.
The documentation for forkProcess seems to say that Handle-based I/O won't work in the child process. I need to communicate with the program I'm running via its standard input and output. Does this mean forkProcess is out of the question?
No. What it means is that, if the child will continue to run in the same Haskell program after forkProcess-ing, any open Handles won't work right. You could fix this with handleToFd and fdToHandle, I suspect, but it's irrelevant because you're going to executeFile instead. - -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAkoB8l4ACgkQIn7hlCsL25U4ZwCePdfbEmXc5n8OJc++jTafUQOX uc8An1XJlXAx5mqYBM5c/iLaGIihq00W =FFS9 -----END PGP SIGNATURE-----
On Wednesday, 06.05.09 at 16:25, Brandon S. Allbery KF8NH wrote:
No. What it means is that, if the child will continue to run in the same Haskell program after forkProcess-ing, any open Handles won't work right. You could fix this with handleToFd and fdToHandle, I suspect, but it's irrelevant because you're going to executeFile instead.
I forkProcess. The parent gets the PID. The child does setResourceLimit, then executeFile, which is done with one of the execvs, which replaces the child process with the program I'm trying to communicate with. So now the program is resource limited and will probably quit if it takes too much CPU time. But the parent just has the child's PID. How is it communicating with the child?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 6, 2009, at 16:39 , brian@lorf.org wrote:
On Wednesday, 06.05.09 at 16:25, Brandon S. Allbery KF8NH wrote:
No. What it means is that, if the child will continue to run in the same Haskell program after forkProcess-ing, any open Handles won't work right. You could fix this with handleToFd and fdToHandle, I suspect, but it's irrelevant because you're going to executeFile instead.
I forkProcess. The parent gets the PID. The child does setResourceLimit, then executeFile, which is done with one of the execvs, which replaces the child process with the program I'm trying to communicate with.
So now the program is resource limited and will probably quit if it takes too much CPU time. But the parent just has the child's PID. How is it communicating with the child?
Create pipes (System.Posix.IO.createPipe) before forkProcess. In the child, close stdin/stdout/stderr handles (which are unusable anyway) as appropriate and dupTo the write pipes to stdout and stderr and read pipe to stdin (again, as appropriate; remember that doing both stdin and stdout means you need to be careful to avoid data starvation deadlocks). In the parent you use fdToHandle to turn the other end of each pipe into a Handle that you can use as normal. You might want to study how to do this in C first, as the System.Posix calls are simple wrappers around the standard POSIX library routines. - -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAkoB+cQACgkQIn7hlCsL25UtDwCfVzY1Qck/+/fvguMHGPVAefMy F7cAoMloJ/4AqKhTHQNtaVbHGhYwylls =5H08 -----END PGP SIGNATURE-----
participants (2)
-
Brandon S. Allbery KF8NH -
brian＠lorf.org