linux-kernel - Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

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-next>] [day] [month] [year] [list]

Date:	Sat, 3 Mar 2007 11:58:17 +0100
From:	"Ihar `Philips` Filipau" <thephilips@...il.com>
To:	"Evgeniy Polyakov" <johnpol@....mipt.ru>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

On 3/3/07, Evgeniy Polyakov <johnpol@....mipt.ru> wrote:
> On Fri, Mar 02, 2007 at 08:20:26PM +0100, Ihar `Philips` Filipau (thephilips@...il.com) wrote:
> > I'm not well versed in modern kernel development discussions, and
> > since you have put the thing into the networked context anyway, can
> > you please ask on lkml why (if they want threadlets solely for AIO)
> > not to implement analogue of recv(*filedes*, b, l, MSG_DONTWAIT).
> > Developers already know the inteface, socket infrastructure is already
> > in kernel, etc. And it might do precisely what they want: access file
> > in disk cache - just like in case of socket it does access recv buffer
> > of socket. Why bother with implicit threads/waiting/etc - if all they
> > want some way to probe cache?
>
> Threadlets can work with any functionas a base - if it would be
> recv-like it will limit possible case for parallel programming, so you
> can code anything in threadlets - it is not only about IO.
>

Ingo defined them as "plain function calls as long as they do not block".

But when/what function could block?

(1) File descriptors. Read. If data are in cache it wouldn't block.
Otherwise it would. Write. If there is space in cache it wouldn't
block. Otherwise it would.

(2) Network sockets. Recv. If data are in buffer they wouldn't block.
Otherwise they would. Send. If there is space in send buffer it
wouldn't block. Otherwise it would.

(3) Pipes, fifos & unix sockets. Unfortunately gain nothing since the
reliable local communication used mostly for control information
passing. If you have to block on such socket it most likely important
information anyway. (e.g. X server communication or sql query to SQL
server). (Or even less important here case of shell pipes.) And most
users here are all single threaded and I/O bound: they would gain
nothing from multi-threading - only PITA of added locking.

What I'm trying to get to: keep things simple. The proposed
optimization by Ingo does nothing else but allowing AIO to probe file
cache - if data there to go with fast path. So why not to implement
what the people want - probing of cache? Because it sounds bad? But
they are in fact proposing precisely that just masked with "fast
threads".

-- 
Don't walk behind me, I may not lead.
Don't walk in front of me, I may not follow.
Just walk beside me and be my friend.
    -- Albert Camus (attributed to)
-
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/