[lkml]   [2007]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
    On Tue, Feb 27, 2007 at 06:52:22AM -0500, Theodore Tso ( wrote:
    > On Tue, Feb 27, 2007 at 01:28:32PM +0300, Evgeniy Polyakov wrote:
    > > Obviously there are bugs, it is simply how things work.
    > > And debugging state machine code has exactly the same complexity as
    > > debugging multi-threading code - if not less...
    > Evgeniy,

    Hi Ted.

    > I think what you are not hearing, and what everyone else is saying
    > (INCLUDING Linus), is that for most programmers, state machines are
    > much, much harder to program, understand, and debug compared to
    > multi-threaded code. You may disagree (were you a MacOS 9 programmer
    > in another life?), and it may not even be true for you if you happen
    > to be one of those folks more at home with Scheme continuations, for
    > example. But it is true that for most kernel programmers, threaded
    > programming is much easier to understand, and we need to engineer the
    > kernel for what will be maintainable for the majority of the kernel
    > development community.

    I understand that - and I totally agree.
    But when more complex, more bug-prone code results in higher performance
    - that must be used. We have linked lists and binary trees - the latter
    are quite complex structures, but they allow to have higher performance
    in searching operatins, so we use them.

    The same applies to state machines - yes, in some cases it is hard to
    program, but when things are already implemented and are wrapped into
    nice (no posix) aio_read(), there is absolutely no usage complexity.

    Even if it is up to programmer to programm state machine based on
    generated events, that higher-layer state machines are not complex.

    Let's get simple case of (aio_)read() from file descriptor - if page is in the
    cache, no readpage() method will be called, so we do not need to create
    some kind of events - just copy data, if there is no page or page is not
    uptodate, we allocate a bio and do not wait until buffers are read - we
    return to userspace and start another reading, when bio is completed and
    its end_io callback is called, we mark pages as uptodate, copy data to userspace,
    and mark event bound to above (aio_)read() as completed.
    (that is how kevent aio works, btw).
    Userspace programmer just calls
    cookie = aio_read();
    or something like that.

    It is simple, it is straightforward, especially if data read must then
    be used somewhere else - in that case processing thread will need to operate
    with main one, which is simple in event model, since there is a place,
    where events of _all_ types are gathered.

    > Regards,
    > - Ted

    Evgeniy Polyakov
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-02-27 13:17    [W:0.022 / U:4.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site