Messages in this thread | | | Date | Tue, 27 Feb 2007 15:11:16 +0300 | From | Evgeniy Polyakov <> | Subject | Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3 |
| |
On Tue, Feb 27, 2007 at 06:52:22AM -0500, Theodore Tso (tytso@mit.edu) 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(); aio_wait(cookie); 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 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/
| |