lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45D3A49B.4030608@goop.org>
Date:	Wed, 14 Feb 2007 16:08:59 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Davide Libenzi <davidel@...ilserver.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ulrich Drepper <drepper@...hat.com>,
	Zach Brown <zach.brown@...cle.com>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system
 call support

Davide Libenzi wrote:
>> Would this work?
>>     
>
> Hopefully the API will simplify enough so that emulation will becomes 
> easier.
>   

The big question in my mind is how all this stuff interacts with
signals.  Can a blocked syscall atom be interrupted by a signal?  If so,
what thread does it get delivered to?  How does sigprocmask affect this
(is it atomic with respect to blocking atoms)?

>> Also, an unrelated question: is there enough control structure in place
>> to allow multiple syslet streams to synchronize with each other with
>> futexes?
>>     
>
> I think the whole point of an async execution of a syscall or a syslet, is 
> that the syscall/syslet itself includes a non interlocked operations with 
> other syscalls/syslets. So that the main scheduler thread can run in a 
> lockless/singletask fashion. There are no technical obstacles that 
> prevents you to do it, bu if you start adding locks (and hence having 
> long-living syslet-threads) at that point you'll end up with a fully 
> multithreaded solution.
>   

I was thinking you'd use the futexes more like barriers than locks. 
That way you could have several streams going asynchronously, but use
futexes to gang them together at appropriate times in the stream.  A
handwavy example would be to have separate async streams for audio and
video, but use futexes to stop them from drifting too far from each other.

    J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ