On Fri, 2 Jan 2004, Jaeger, Gerhard wrote: > Hi, > > On Mittwoch, 31. Dezember 2003 18:10, m. allan noah wrote: > > i am converting the fujitsu backend to use sanei_thread instead of fork. > > okay - good ;-) > > > > > in reading the threading code, i found something that i dont understand, > > and was hoping someone who knows a bit more could explain it to me: > > let's try. > > > in the function sanei_thread_waitpid(), the #ifdef PTHREAD section always > > returns pid (around line 354). but farther down, in the #else section, the > > return val from the waitpid() call is returned (which is the pid on > > success, but 0 or -1 otherwise) > > > > so if you are calling sanei_thread_waitpid() and there is an error, you > > might, or might not, get a negative return value? > > The idea is, that sanei_thread_waitpid should be some replacement for waitpid, > and if this waitpid fails, you should get back exactly the code it delivers... > Only the case ECHILD is handled different (guess it was because of some > internals in the plustek backend ;-) )
ok, i understand this, sanei_thread_waitpid should mimic waitpid() functionality.... > In case of the pthread_join stuff, there's no proper replacement for waitpid, > and that's why this part always returns the pid (maybe this can also be > done better, but currently I don't see any problems there) > ok, so sanei_thread_waitpid does not mimic waitpid, in the case of threading? > So you can use sanei_thread_waitpid the same way you have used it in > your backend... unless threading is used, cause i cant use the return val in that case, instead i must use the status pointer? seems like this abstraction layer is not quite abstracted enough... > > > am i not reading this code correctly? > > no, you're reading it correctly... > > Hope this helps a bit, > Gerhard > > thanks for the tips, thought i was missing something... allan -- "so don't tell us it can't be done, putting down what you don't know. money isn't our god, integrity will free our souls" - Max Cavalera
