(no subject)

[michi@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]

From michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Fri Apr  3 07:06:41 2009
Date: Fri, 3 Apr 2009 07:06:41 +0200
From: Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
To: Peter Teoh <htmldeveloper@xxxxxxxxx>
Cc: Devesh Sharma <devesh28@xxxxxxxxx>, kernelnewbies@xxxxxxxxxxxx
Subject: Re: Usage of Semaphore with a workqueue
Message-ID: <20090403050641.GA1739@grml>
References: <309a667c0904010812p23ddde3fjda53a5d3e0250075@xxxxxxxxxxxxxx> <804dabb00904011706h2763da72i1ff000ca7cf79bde@xxxxxxxxxxxxxx> <20090402175526.GA1724@grml> <804dabb00904021752v73e4d15codf385a3fdbb8a509@xxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <804dabb00904021752v73e4d15codf385a3fdbb8a509@xxxxxxxxxxxxxx>
User-Agent: Mutt/1.5.18 (2008-05-17)
Status: RO
Content-Length: 2441
Lines: 61

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



--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ