In the converting of flex and bison fork with fd to m4 business, I used the child to write a /tmp file for the parent to open at waitpid(). I had a report from Jeffrey that the /tmp file was still open when the parent tried to open it. I was thinking this was the fault of our waitpid() but I see in the linux world the file writing job could be still unfinished even after the write function is successful. Hence the existence of the O_SYNC flag and the fsync() function.
Is the fsync() function going to do anything worthwhile either in the unixlib child or the parent? Without going into alternative waitpid signalling schemes, that could end up with the same result. I'm thinking that a simple fix, might be to add a sleep for the parent in the event the file isn't available. I never had the error while testing, so I can't replicate it. Could be because I was using scrap in RAM: and the writing was faster or the files weren't big enough. Ronald _______________________________________________ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
