Thank you Michael, In general I must agree with a lots of points below, other times, I cannot, because there is nothing to disagree with. (ie....pending lots of other unknown variable...nothing affirmative can be asserted). On Fri, Apr 3, 2009 at 12:39 PM, Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi! > > On 14:45 Fri 03 Apr , Peter Teoh wrote: >> Er....yes, i understand what u are saying.....but then I am lost over >> your original question. >> >> Can you re-explain your original question again? Now I don't quite understand. > > Devesh wanted to do trylock of a semaphore inside a workqueue and return > ERESTARTSYS if locking fails. There are some things which are wrong with > this approach. > > 1) Mutexes should be prefered over semaphores, if possible. If it is not > possible, it might be a case which is not well suited for a workqueue. e.g. > you can create a request queue and use a semaphore for counting the number of > requests in the queue and sleeping if there are no requests until one arrives. > Yes, my current understanding immediate favor mutex over semaphore. Depending on applications. But the traditional semaphore has been replaced by System V semaphore in the kernel, which seemingly had a lot of variations. (Wolfgang described it as not easily understood) i still have yet to fully understand the difference between Posix and System V semaphore too. But yet, mutex are much simpler. And workqueue ....yes, it should be used. Mainly reason is because it is sleepable. Another is that it execute in the process context of the caller. So it can return any error condition and this will go direct to the userspace application that call it. (as mentioned in article below, it is also THE ONLY option if u want your bottom half to execute in the process context - any other option/context u CANNOT return any error condition, as it will go to nowhere) http://www.linuxjournal.com/article/6916 As for ERESTARTSYS or EAGAIN or EINTR etc....it all depends on WHICH bottomhalf interrupt handler function u can talking, and more important, whether u are returning to userspace or to another part in the kernel (eg, VFS layer seemed to be responsible for handling ERESTARTSYS). The standards (which is your point Michael dear) seemed to be captured in this remark: (started from http://www.linuxtv.org/pipermail/linux-dvb/2005-August/004018.html) /* * These should never be seen by user programs. To return one of ERESTART* * codes, signal_pending() MUST be set. Note that ptrace can observe these * at syscall exit tracing, but they will never be left for the debugged user * process to see. */ in include/linux/errno.h. So yes, Michael is right, ERESTARTSYS should not be returned if the path of processing is back to the userspace. hmmmm......i never knew these before.....not sure if there exists a POSIX/SystemV standard for these definition? Looking through all the samples in drivers directory.....many are using each of these different error conditions (ERESTARTSYS, EAGAIN, EINTR etc)......I have yet to fully understood them. > 2) I have never used trylock and I still do not know what he wants to do with > it. > > 3) ERESTARTSYS is for use with the _interruptable functions of mutex_lock > and others. It makes only sense inside system calls, because its purpose is > to exit the system call prematurely in order to let a signal be delivered to > the user space process. The system call will then fail with errno set to > EINTR. > 3.1) Returning ERESTARTSYS in a workqueue will not not work. The workqueue > function has to return void, so the return code will get lost. this is where u lost me......which workqueue function? but to be more exact.....MOST bottom half handler functions has to return something except for like suspend() etc. And each of these BH function are executing in the workqueue...... > 3.2) Returning ERESTARTSYS is only valid for the _interruptable functions if > a signal is pending. Returning it after trylock if something is currently > locked will not work (why would you want to do this anyway?). > > -Michi > -- > programing a layer 3+4 network protocol for mesh networks > see http://michaelblizek.twilightparadox.com > > PS: after writing all these, just read that mutex == binary semaphore!!!! (from Wolfgang) so yes, mutex is much simpler, but it is also a semaphore. :-). -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
