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", |