Email list hosting service & mailing list manager

Re: [scheme-reports-wg2] Threads and futures Linas Vepstas (19 Mar 2022 05:54 UTC)
Re: [scheme-reports-wg2] Threads and futures Marc Nieper-Wißkirchen (19 Mar 2022 08:24 UTC)
Re: [scheme-reports-wg2] Threads and futures John Cowan (19 Mar 2022 18:57 UTC)
Re: [scheme-reports-wg2] Threads and futures Linas Vepstas (19 Mar 2022 20:04 UTC)
Re: [scheme-reports-wg2] Threads and futures Marc Nieper-Wißkirchen (19 Mar 2022 22:11 UTC)
Re: [scheme-reports-wg2] Threads and futures Linas Vepstas (20 Mar 2022 07:50 UTC)
Re: [scheme-reports-wg2] Threads and futures John Cowan (20 Mar 2022 22:34 UTC)
Re: [scheme-reports-wg2] Threads and futures Marc Feeley (21 Mar 2022 04:49 UTC)
Re: [scheme-reports-wg2] Threads and futures Marc Nieper-Wißkirchen (21 Mar 2022 06:28 UTC)
Re: [scheme-reports-wg2] Threads and futures Marc Nieper-Wißkirchen (21 Mar 2022 06:54 UTC)
Re: [scheme-reports-wg2] Threads and futures Ray Dillinger (21 Mar 2022 19:00 UTC)
Re: [scheme-reports-wg2] Threads and futures Dr. Arne Babenhauserheide (21 Mar 2022 16:54 UTC)
Re: [scheme-reports-wg2] Threads and futures Marc Nieper-Wißkirchen (21 Mar 2022 16:04 UTC)
Re: [scheme-reports-wg2] Threads and futures Taylan Kammer (23 Mar 2022 14:20 UTC)
Re: [scheme-reports-wg2] Threads and futures Marc Nieper-Wißkirchen (23 Mar 2022 14:28 UTC)
Re: [scheme-reports-wg2] Threads and futures Dr. Arne Babenhauserheide (23 Mar 2022 15:40 UTC)
Re: [scheme-reports-wg2] Threads and futures Marc Nieper-Wißkirchen (23 Mar 2022 15:34 UTC)
Re: [scheme-reports-wg2] Threads and futures Dr. Arne Babenhauserheide (23 Mar 2022 22:08 UTC)
Re: [scheme-reports-wg2] Threads and futures Ray Dillinger (01 Apr 2022 23:04 UTC)
Re: [scheme-reports-wg2] Threads and futures Per Bothner (01 Apr 2022 23:21 UTC)
Re: [scheme-reports-wg2] Threads and futures Ray Dillinger (01 Apr 2022 23:28 UTC)
Re: [scheme-reports-wg2] Threads and futures Per Bothner (01 Apr 2022 23:50 UTC)
Re: [scheme-reports-wg2] Threads and futures Ray Dillinger (02 Apr 2022 00:01 UTC)
Re: [scheme-reports-wg2] Threads and futures Per Bothner (02 Apr 2022 00:35 UTC)
Re: [scheme-reports-wg2] Threads and futures Linas Vepstas (10 Apr 2022 23:46 UTC)
Re: [scheme-reports-wg2] Threads and futures Linas Vepstas (27 Mar 2022 16:54 UTC)

Re: [scheme-reports-wg2] Threads and futures Marc Feeley 21 Mar 2022 04:49 UTC

The SRFI-18 thread-specific and thread-specific-set! procedures are a primitive way of attaching local storage to a thread.  It essentially gives you a single cell of local storage, but a larger data structure can be put in that cell to give more storage.  That mechanism is low-level but sufficient for the programmer to create his own higher level thread abstraction.

Gambit offers another mechanism that is based on extensible records (i.e. the definition of record subtypes).  Threads are essentially records of type “thread”.  Subtypes of the thread type can be defined using

     (define-type-of-thread foo
       field1
       field2
       …)

If t is a “foo” thread, then (foo-field1 t) and (foo-field1-set! t x) can be used to read and write field1 of that thread.  So these fields are a form of thread local storage.  Starting a thread is however more involved because the thread needs to be initialized before it is started:

     (define t (make-foo 42 …))

     (write (foo-field1 t)) ;; prints 42

     (thread-init! t (lambda () (write (foo-field1 (current-thread))))

     (thread-start! t) ;; will start the thread, and it will print 42

This mechanism gives an O(1) access time for thread local storage, which is hard to beat.

Marc

> On Mar 20, 2022, at 6:34 PM, John Cowan <xxxxxx@ccil.org> wrote:
>
>
>
> On Sat, Mar 19, 2022 at 3:58 PM Linas Vepstas <xxxxxx@gmail.com> wrote:
>
> Most languages try to be reasonable, but they're not putting design decisions under a performance microscope. Is this where you want to be with scheme?
>
> Those who want performance above all else may move away from C++ someday, but it isn't going to be towards any Lisp.  Lisp, like Basic and many other languages, has an inferiority complex about speed: at some point the most readily available implementation was a slow interpreter, and the whole language got tarred with that brush.
>
> What's the charter for scheme, really? "To be popular like python" seems unlikely; even MIT is no longer teaching from SICP.
>
> Because MIT decided that the comp-sci course every student takes should now be about writing glue rather than data structures and algorithms, a plausible choice in the current environment.  Of course Python is not *especially* for writing glue, it's just that people do in fact write glue in it.  Similarly, Python's popularity is primarily a result of being in the right place (not Japan like Ruby) at the right time (when people were fed up with Perl).  It wasn't designed with popularity in mind, any more than Java was designed with performance in mind (it just so happened that advanced JIT work was being done at the same time in the same company).
> I'd like scheme to be as-fast-as-possible, as what else is it offering the world?
>
> Syntax extension, for one thing: the Lisps are tools that provide expert users with a huge amount of expressive power.  Of course, many programmers think expressive power is a Bad Thing, and in clumsy hands it is dangerous.  Scheme, unlike CL, provides multiple styles of syntax extension from most to least safe.