lkml.org 
[lkml]   [2002]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Futex Generalization Patch
Date
On Wednesday 10 April 2002 03:59 pm, Bill Abt wrote:
> On 04/10/2002 at 02:47:50 PM AST, Hubertus Franke <frankeh@watson.ibm.com>
>
> wrote:
> > The current interface is
> >
> > (A)
> > async wait:
> > sys_futex (uaddr, FUTEX_AWAIT, value, (struct timespec*) sig);
> > upon signal handling
> > sys_futex(uaddrs[], FUTEX_WAIT, size, NULL);
> > to retrieve the uaddrs that got woken up...
>
> This is actually the preferred way. I must've misinterpeted what you said
> earlier. I believe this is actually a more generic way of handling. A
> thread package can specify the signal to used much in the way the current
> LinuxThreads pre-allocates and uses certain real-time signals...
>
> > I am mainly concerned that SIGIO can be overloaded in a thread package ?
> > How would you know whether a SIGIO came from the futex or from other file
> >
> > handle.
>
> By keep with the original interface, we don't have to contend with this
> problem. The thread package can use the signal that most suits its'
> implementation...
>
> Make sense?
>

I wasn't precise...
There are ++ and -- for the file descriptors approach
++)
(a) it automatically cleans up the notify queue associated with the FD.
[ notify queue could still be global, if we want that ]
when the process disappears, no callback required in do_exit()
--) There is more overhead in the wakeup and the wait because I need to
move from the fd to the filestruct which is always some lookup and
I have to verify that the file descriptor is actually a valid /dev/futex
file (yikes).

Another problem I see is that we only have one additional
argument (void *utime) to piggyback the fd and the signal on.

What could be done is the following.
Make utime a (void *utime) argument
In FUTEX_WAIT interpret it as a pointer <struct timespec>
In FUTEX_AWAIT inteprest it as { short fd, short sig };
There should be no limitation by casting it to shorts ?

Comments, anyone....

I suggest, we leave it as is right now until more comments come.

> Regards,
> Bill Abt
> Senior Software Engineer
> Next Generation POSIX Threading for Linux
> IBM Cambridge, MA, USA 02142
> Ext: +(00)1 617-693-1591
> T/L: 693-1591 (M/W/F)
> T/L: 253-9938 (T/Th/Eves.)
> Cell: +(00)1 617-803-7514
> babt@us.ibm.com or abt@us.ibm.com
> http://oss.software.ibm.com/developerworks/opensource/pthreads

--
-- Hubertus Franke (frankeh@watson.ibm.com)
-
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:25    [W:0.033 / U:3.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site