lkml.org 
[lkml]   [2002]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Semaphore behavior
> I wanted to clarify my understanding of the behavior of semaphores
> on the i386 architecture, as I understand it.
>
> 1. I grab a semaphore and I am open to accepting signals
> (down_interruptible)
> 2. I am interrupted by a user process using ctrl-C or some other
> method of signal delivery.
> 3. After this point, I cannot grab *ANY* semaphore using
> (down_interruptible), since the semaphore implementation checks for
> pending signals and if there are signals pending, it does not
> grant me the semaphore.
>
> So, the only option I have after (2) to use down_interruptible again
> is
>
> a. Flush the signal.
> b. Handle the signal.
>
> Please cc your replies to me
>
> Is my assessment correct?

You are right, AFAIK. You should do down_interruptible if you expect it may
take long to get the semaphore. If you are interrupted, you should return
to userland (with ERESTARTSYS or EINTR error) to have the signal handled.
The trouble is, that when you return ERESTARTSYS, the syscall may, but need not
to be restarted. And unfortunately you can never tell the restarted syscall from
a new invocation.

--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.042 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site