Am 03.07.2014 17:34, schrieb Daniel Leslie:

Unless I missed a radical change in Chicken, its SRFI-18 threads are green threads and not real system threads. As a result, blocking operations will block all threads and no real gain is had from the hardware's support for multithreading.

Because of those issues I suggest avoiding SRFI-18 threads altogether. They aren't worth the hassle.

-Dan


Depends... If your job is to manage a lot of network i/o or other asynchronous events, what would you do without SRFI-18? Probably write your own event loop. That would be equivalent to green threads in turn.

Having said that let me add a note about my personal taste: I'm using a wrapper over SRFI-18 (which could be implemented without SRFI-18) to provide a more Schemish API to threads. Like:

(!map <proc> <list>)
(!apply <proc> <list>)

Which would do the same thing as "map" and "apply", just returning a promise to the result and apply <proc> in parallel to the calling thread and (in case of !map) in parallel to all elements in the list.

So yes, SRFI-18 is kind of a hassle. But green threads retain their purpose.

On 3 Jul 2014 04:13, "Kristian Lein-Mathisen" <[email protected] <mailto:[email protected]>> wrote:

    That is strange, I've experienced alex's problem too - having to
    yield a little to give the REPL some room.

    Anyhow, for others who might come across this thread: alex's idea
    works great, but you need to be careful with blocking IO on your
    REPL. If you don't use parley <http://api.call-cc.org/doc/parley>
    or something similar, chances are that your REPL srfi-18-thread
    will block your srfi-18-game-thread while it's waiting for IO.

    K.


    On Wed, Jul 2, 2014 at 9:07 PM, John Cowan <[email protected]
    <mailto:[email protected]>> wrote:

        alex scripsit:

        > I had some trouble with this last part at first: the
        original thread
        > waited several seconds before evaluating my input. I think
        that the
        > fix was nothing more than calling thread-yield! every loop
        > iteration.

        If you are depending on thread-yield! for correctness rather than
        efficiency, you are doing something wrong (but I don't know what).
        SRFI 18 schedulers are not required to be fair in any way.

        --
        John Cowan http://www.ccil.org/~cowan
        <http://www.ccil.org/%7Ecowan> [email protected]
        <mailto:[email protected]>
        He that would foil me must use such weapons as I do, for I
        have not
        fed my readers with straw, neither will I be confuted with
        stubble.
                                --Thomas Vaughan (1650)

        _______________________________________________
        Chicken-users mailing list
        [email protected] <mailto:[email protected]>
        https://lists.nongnu.org/mailman/listinfo/chicken-users



    _______________________________________________
    Chicken-users mailing list
    [email protected] <mailto:[email protected]>
    https://lists.nongnu.org/mailman/listinfo/chicken-users



_______________________________________________
Chicken-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/chicken-users

_______________________________________________
Chicken-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/chicken-users

Reply via email to