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. On Fri, Apr 3, 2009 at 1:06 PM, Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi! > > On 20:52 Thu 02 Apr , Peter Teoh wrote: >> Hi Michael, >> >> Nice to discuss with you. >> >> On Thu, Apr 2, 2009 at 1:55 PM, Michael Blizek >> <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> > Hi! > > ... > >> > What makes you think that this is called in workqueue context? The only >> > caller of this function I have found is in drivers/char/rocket.c >> > "static const struct tty_operations rocket_ops". It is probably called >> > in system call context. For this reason, the mutex is locked interruptible >> >> The concern is not workqueue vs no workqueue context. It is >> sleepable vs non-sleepable context. rp_write() is called in >> tty_operations's write() API, so if rp_put_char() can sleep (which is >> tty's put_char() API), i don't see why rp_write() cannot sleep). So >> mutex_lock() could have been used, but then this could wait forever >> (which is the case for rp_put_char()), so it is better to return an >> error condition. > > The point is not sleepable vs non-sleepable context, but sleepable system > call vs sleepable non system call context. The difference is that system > call context has a user space thread/process assigned and waiting for the > end of the system call. As long as the system call is running, signals > cannot be received. So if you wait for something which can take some time, > you might want to make sure that you can exit early. The _interrupt functions > of mutex_lock and other apis take care of this. > >> Anyway, this is an example of interrupt sending work to be done to >> another non-interrupt context (sleepable). > > This is not about interrupt sending, but signal sending. Interrupts can > arrive and be processed any time, the sleepable context will be put to sleep > whether you use mutex_lock or mutex_lock_interruptable. > >> If u want exact identical example of interrupt sending work to a >> workqueue (which is also sleepable) I found this >> drivers/memstick/core/memstick.c. except that it is not ERESTARTSYS, >> but EAGAIN, which I think should be more appropriate for a harmless >> device :-). > > EAGAIN means somebody is doing non-blocking IO and no data can be read/written > without blacking. > >> (ERESTARTSYS and EINTR sometimes is intermixable????, >> tell me more :-)) > > I do not know the exact semantics, but I do not think so: > include/asm-generic/errno-base.h > include/linux/errno.h > > -Michi > -- > programing a layer 3+4 network protocol for mesh networks > see http://michaelblizek.twilightparadox.com > > -- 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
