[Chicken-users] process-wait

[chick0]

Hello,

> ***** Message sent: 01 Sep 2011 14:16:44 +0200 *****

> For quite some time I've been wondering why my app runs only about

> twice as fast on chicken compared to rscheme (given the benchmark

> style performance of chicken code).

> strace was my friend to pin this down to process-wait. From the

> manual: "Suspends the current process...Note that suspending the

> current process implies that all threads are suspended as well."

> Too bad, my app spent it's time waiting for irrelevant processes,

> not running useful threads as I'd like it to.

> This shouldn't be too hard to fix, I thought - and wrote the code

> I'll paste and comment. (With the intention that this might

> go into the posix unit eventually.) Once the issues I have are

> resolved, that is. However those are harder than I expected:

> (Side note: even with bad the code here my app feels much

> better, since the "coughing" is gone.)

...

> The idea is to convert (process-wait pid #f) into

> (process-wait pid #t) and block the current tread only

> when the first result is zero.

Sounds indeed frustrating. I've run across similar problems while writing a multitasking web server. It uses process-fork to create child processes which handle the client requests. Under Linux, the parent may wait, or not, for the child to finish, If not, the child doesn't "go away"--it's a "zombie"--until the parent ends, unless the default signal handler flags are set to a NOWAIT value.

It's not entirely clear what your code is trying to do. I gather that somehow child processes are created, and SRFI-18 threads are waiting for a child to signal its termination. AFAIK it's usually troublesome to combine "green" threading with OS native multi-threading/tasking, because all the green theads are in running in one process and only "know" what's happening in the process they are running in. If this process is waiting, then none of the threads can do anything. (BTW, in Linux, and perhaps other OS, processes and kernel threads are basically the same thing.)

If multiple processes are needed for the application, then some other approach is probably going to be necessary. One thing I've experimented with is using POSIX mmap and semaphore facilities. Mmap is already in the posix unit. It's not too difficult to wrap native semaphore functions with the Chicken FFI. Some preliminary testing suggests this works adequately and doesn't require waiting on child processes.

When I have a little more time to put it together, it might make a useful little egg to contribute. I'll have to work on it.

Hope I haven't missed something you were getting at.

Thanks,

Jules.