| 51 |
|
* Note the differences between this and the simpler ray_trace() |
| 52 |
|
* call. In particular, the call may or may not return a value |
| 53 |
|
* in the passed ray structure. Also, you need to call rayorigin() |
| 54 |
< |
* yourself, which is normally for you by ray_trace(). The |
| 55 |
< |
* great thing is that ray_pqueue() will trace rays faster in |
| 54 |
> |
* yourself, which is normally called for you by ray_trace(). The |
| 55 |
> |
* benefit is that ray_pqueue() will trace rays faster in |
| 56 |
|
* proportion to the number of CPUs you have available on your |
| 57 |
|
* system. If the ray queue is full before the call, ray_pqueue() |
| 58 |
|
* will block until a result is ready so it can queue this one. |
| 81 |
|
* ray_psend(&myRay); |
| 82 |
|
* } |
| 83 |
|
* |
| 84 |
< |
* The ray_presult() and/or ray_pqueue() functions may then be |
| 85 |
< |
* called to read back the results. |
| 84 |
> |
* Note that it is a fatal error to call ra_psend() when |
| 85 |
> |
* ray_pnidle is zero. The ray_presult() and/or ray_pqueue() |
| 86 |
> |
* functions may be called subsequently to read back the results. |
| 87 |
|
* |
| 88 |
|
* When you are done, you may call ray_pdone(1) to close |
| 89 |
|
* all child processes and clean up memory used by Radiance. |
| 100 |
|
* If you just want to reap children so that you can alter the |
| 101 |
|
* rendering parameters without reloading the scene, use the |
| 102 |
|
* ray_pclose(0) and ray_popen(nproc) calls to close |
| 103 |
< |
* then restart the child processes. |
| 103 |
> |
* then restart the child processes after the changes are made. |
| 104 |
|
* |
| 105 |
|
* Note: These routines are written to coordinate with the |
| 106 |
|
* definitions in raycalls.c, and in fact depend on them. |
| 107 |
|
* If you want to trace a ray and get a result synchronously, |
| 108 |
< |
* use the ray_trace() call to compute it in the parent process. |
| 108 |
> |
* use the ray_trace() call to compute it in the parent process |
| 109 |
> |
* This will not interfere with any subprocess calculations, |
| 110 |
> |
* but beware that a fatal error may end with a call to quit(). |
| 111 |
|
* |
| 112 |
|
* Note: One of the advantages of using separate processes |
| 113 |
|
* is that it gives the calling program some immunity from |
| 114 |
|
* fatal rendering errors. As discussed in raycalls.c, |
| 115 |
|
* Radiance tends to throw up its hands and exit at the |
| 116 |
|
* first sign of trouble, calling quit() to return control |
| 117 |
< |
* to the system. Although you can avoid exit() with |
| 117 |
> |
* to the top level. Although you can avoid exit() with |
| 118 |
|
* your own longjmp() in quit(), the cleanup afterwards |
| 119 |
|
* is always suspect. Through the use of subprocesses, |
| 120 |
|
* we avoid this pitfall by closing the processes and |
| 123 |
|
* of these calls, you can assume that the processes have |
| 124 |
|
* been cleaned up with a call to ray_close(), though you |
| 125 |
|
* will have to call ray_pdone() yourself if you want to |
| 126 |
< |
* free memory. Obviously, you cannot continue rendering, |
| 127 |
< |
* but otherwise your process should not be compromised. |
| 126 |
> |
* free memory. Obviously, you cannot continue rendering |
| 127 |
> |
* without risking further errors, but otherwise your |
| 128 |
> |
* process should not be compromised. |
| 129 |
|
*/ |
| 130 |
|
|
| 131 |
|
#include <stdio.h> |
| 500 |
|
ray_pnprocs--; |
| 501 |
|
close(r_proc[ray_pnprocs].fd_recv); |
| 502 |
|
close(r_proc[ray_pnprocs].fd_send); |
| 503 |
< |
while (wait(&status) != r_proc[ray_pnprocs].pid) |
| 504 |
< |
; |
| 503 |
> |
if (waitpid(r_proc[ray_pnprocs].pid, &status, 0) < 0) |
| 504 |
> |
status = 127<<8; |
| 505 |
|
if (status) { |
| 506 |
|
sprintf(errmsg, |
| 507 |
|
"rendering process %d exited with code %d", |
