[lkml]   [2007]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling
    > They are NOT the generic co-routine that some languages support natively. 
    > So I think trying to call them coroutines would be even more misleading
    > than calling them fibrils.

    Its actually pretty damned close the Honeywell B co-routine package, with
    a kernel twist to be honest.

    > ends up looking like. There's a good reason why people program mostly in
    > linear flow: that's how people think consciously - even if it's obviously
    > not how the brain actually works).

    The IRQ example below is an example of how it linearizes - so it cuts
    both ways like most tools, admittedly one of the blades is at the handle
    end in this case ...

    > Basically, what I'm hoping can come out of this (and this is a simplistic
    > example, but perhaps exactly *because* of that it hopefully also shows
    > that we canactually make *simple* interfaces for complex asynchronous
    > things):
    > struct one_entry *prev = NULL;
    > struct dirent *de;
    > while ((de = readdir(dir)) != NULL) {
    > struct one_entry *entry = malloc(..);
    > /* Add it to the list, fill in the name */
    > entry->next = prev;
    > prev = entry;
    > strcpy(entry->name, de->d_name);
    > /* Do the stat lookup async */
    > async_stat(de->d_name, &entry->stat_buf);
    > }
    > wait_for_async();

    The brown and sticky will hit the rotating air impeller pretty hard if you
    are not very careful about how that ends up scheduled. Its one thing to
    exploit the ability to pull all the easy lookups out in advance, and
    another having created all the parallelism to turn into into sane disk
    scheduling and wakeups without scaling hit. But you do at least have the
    opportunity to exploit it I guess.

    > > You get some other funny things from co-routines which are very powerful,
    > > very dangerous, or plain insane
    > You forgot "very hard to think about".

    I'm not sure handing a fibril off to another task is that hard to think
    about. It's not easy to turn it around as an async_exit() keeping the
    other fibrils around because of the mass of rules and behaviours tied to
    process exit but its perhaps not impossible.

    Other minor evil. If we use fibrils we need to be careful we
    know in advance how many fibrils an operation needs so we don't deadlock
    on them in critical places like writeout paths when we either hit the per
    task limit or we have no page for another stack.

    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-02 22:21    [W:0.022 / U:4.008 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site