styx services with support for concurrent operations

Hi!

I wonder is there any styx service in Inferno with support for concurrent
operations? (The sys->export() support it, of course, but I'm speaking
about services which export own virtual fs - like dossrv or ftpfs.)

There styxflush.m, but it doesn't used by any app.

The styxservers.m has complex enough interface, run (usually) using 3
threads, but... doesn't support concurrent operations (and because of this
it able to use bare Tflush handler).

The ftpfs.b Tflush handler leave no chances it support concurrent requests
too...

I was unable to find even one concurrent styxfs application (i.e. which
able to receive next Tmsg without sending reply to previous Tmsg - and so
support more than one tag at once, handle flushes, etc.). All applications
which able to handle concurrent requests do either sys->file2chan() or
sys->export() and so have Inferno kernel handle concurrency for them.

    Actually there a little reason for, say, 9660srv or dossrv or even
    keyfs to support concurrent access - they all should be able to serve
    incoming requests without delays. But non-concurrent ftpfs?! Or ftpfs
    designed to be used in way similar to usual console ftp client (get
    file, wait until it downloaded, put file, wait until it uploaded, get
    next file, wait...) and not like disk fs (read/write many files
    concurrently)?

Maybe I miss something and support for concurrent requests is something

emu hangs on linux-2.6.27 (x86_64)

Re: emu hangs on linux-2.6.27 (x86_64)

Hi!

On Sat, Nov 01, 2008 at 07:27:11PM +0100, Ostap Cherkashin wrote:
> Any ideas? Does anyone else experience this problem?

http://code.google.com/p/inferno-os/issues/detail?id=121

--

-- 
			WBR, Alex.

Re: emu hangs on linux-2.6.27 (x86_64)

does it work if you comment out setting of CLONE_PTRACE in emu/Linux/os.c?

From: Alex Efros <powerman@...>
Subject: Re: [inferno-list] emu hangs on linux-2.6.27 (x86_64)
Date: 2008-11-02 04:56:34 GMT

Hi!

On Sat, Nov 01, 2008 at 07:27:11PM +0100, Ostap Cherkashin wrote:
> Any ideas? Does anyone else experience this problem?

http://code.google.com/p/inferno-os/issues/detail?id=121

--

-- 
			WBR, Alex.

Re: emu hangs on linux-2.6.27 (x86_64)

Re: emu hangs on linux-2.6.27 (x86_64)

>Yes, it works with CLONE_PTRACE commented out (I mentioned this in the original email).

sorry, i missed that because i was answering messages in reverse order.

anyway: it seems to be a Linux bug, not Inferno's. (possibly the real bug is having that flag at all,
but in some recent linux patches it is not handled well.)
the flag only matters if you need to gdb emu, which few people do,
so it should be fine just to leave it out until Linux is fixed.

Re: styx services with support for concurrent operations

inferno-list-admin@... wrote on 11/01/2008 01:08:58 PM:

> I was unable to find even one concurrent styxfs application (i.e. which
> able to receive next Tmsg without sending reply to previous Tmsg - and so
> support more than one tag at once, handle flushes, etc.). All
applications
> which able to handle concurrent requests do either sys->file2chan() or
> sys->export() and so have Inferno kernel handle concurrency for them.

Take a look at /appl/cmd/wmexport.b
That's the model I've followed for creating a concurrent styxfs..

Caerwyn

Re: styx services with support for concurrent operations

> Take a look at /appl/cmd/wmexport.b
> That's the model I've followed for creating a concurrent styxfs..

actually, although i wrote it, i'm not sure i'd recommend wmexport as
an example to follow. i don't think it gets the correct flush semantics
(which i've found surprisingly hard to get right with genuinely concurrent requests,
which is why i wrote styxflush(2))

the motivating example for this was the grid scheduler 
(see http://code.google.com/p/inferno-owen/source/browse/trunk/appl/cmd/owen/scheduler.b)
where constant hammering meant that most of the possible flush permutations
eventually turned up (in the form of bugs!)

i've since modified that program (and wmexport) to use styxflush;
though, despite trying to model it in spin, i'm still not *entirely* convinced it's correct.

i'd still recommend using it though. it should make life easier.

  cheers,
    rog.

reliability under high load

Hi!

Please look at http://code.google.com/p/inferno-os/issues/detail?id=147

Can anybody comment this issue? Charles tend to not reply on such issues
(you can also check similar issues 117 and 122), but such issues become
real blocker for me: every time I try to use Inferno under high load I hit
some nasty bug (like race condition or queue overflow).

If Inferno doesn't designed to work under high load on modern server
hardware (I believe it's quite stable under "high load" on embedded
devices :)) then Inferno unsuitable for most of my tasks. :(

I hope this isn't the case, and I just was unlucky enough to hit few
existing bugs while in general Inferno should work reliable under high load
(think c10k network service - up to several thousands of threads, spawned
and exited (or killed because of timeout) every few seconds, doing a lot
of file/network and channel I/O).

Previously I benchmarked Inferno performance for such tasks, and it looks
promising... but these bugs make me very sad and unenthusiastic.

--

-- 
			WBR, Alex.

Re: reliability under high load

>Can anybody comment this issue? Charles tend to not reply on such issues
>(you can also check similar issues 117 and 122), but such issues become

that's because i'm fixing them, and it's not trivial.