Summary: | ASTERISK-07759: [patch] vfork() in asterisk.c | ||
Reporter: | nick gavrikov (nick gavrikov) | Labels: | |
Date Opened: | 2006-09-18 04:22:35 | Date Closed: | 2006-10-18 16:07:00 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) asterisk.c.r43247.2.diff | |
Description: | Here is from man-pages about vfork(): the behaviour is undefined if the process cre- ated by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit() or one of the exec() family of functions. So, child can not do following: 1. close opened file descriptors 2. set priority to 0 I don't have much experience using vfork() but this man-page is a way to think. Do you really know what are you doing? | ||
Comments: | By: Serge Vecher (serge-v) 2006-09-18 10:10:50 what's the actual breakage? By: Joshua C. Colp (jcolp) 2006-09-18 15:00:58 Okay, the code has been changed to use fork whenever possible and only use vfork in last resort times... there's not much else we can do besides that. By: nick gavrikov (nick gavrikov) 2006-09-19 06:44:20 Remember, you still cannot make any modifications to variables and calls to another functions. I think better will leave untouched priority and file handles. I attached a patch. By: nick gavrikov (nick gavrikov) 2006-09-19 06:58:17 sorry, first file has a misprint By: Joshua C. Colp (jcolp) 2006-10-18 16:06:59 Fixed in 1.4 as of revision 45595 and trunk as of revision 45596. Thanks for putting up with me taking a bit to understand why it really is bad. Peace! |