Re: futures and parallel forms in Guile and Bigloo

 Hello, Sven,
I got a chance to look at the jvm issues this weekend and have made an update that results in a mostly working implementation; there still remains a race condition when shutting down an executor that results in futures being in a finished state instead of the expected terminated state at times. I will continue to look into this but don't see it as super critical. As before, changes were required to the bigloo pthread library, I refactored the bglpmutex class to use ReentrantLock. This gives the jvm version of the pthread library proper recursive mutexes. The changes can be found at https://github.com/donaldsonjw/bigloo-1/tree/pthread_modifications. 

If you get a chance to try it out, let me know what you think.
Best Regards,Joseph Donaldson

.


    On Sunday, September 6, 2020, 12:25:14 PM PDT, Joseph Donaldson <[email protected]> wrote:  
 
 Hello, Sven,
I took a look at porting scheme-concurrent to Bigloo. The results can be found at https://github.com/donaldsonjw/bigloo-concurrent. The native back-end passes all the tests but there are still some issues with the jvm back-end; I will continue to work on it. While doing the port, I made a few changes to Bigloo. These are linked from the bigloo-concurrent README. I have made a pull request to have the changes included in the Bigloo mainline.
Let me know what you think.
Best Regards, Joseph Donaldson
 
 
  On Thu, Aug 20, 2020 at 8:34 AM, Sven Hartrumpf<[email protected]> wrote:   Hello Joseph.

Thanks for your message and the link to hop code.
I must admit that this looks a little bit scary to me.
Maybe it is easier to port https://github.com/ktakashi/scheme-concurrent
(which already runs on several Schemes) to Bigloo?
It was presented at the Scheme Workshop 2016:
http://schemeworkshop.org/2016/ (it's the second talk)

Greetings
Sven

Joseph wrote, 2020-08-06 17:30:
> Hello, Sven,
>
> Given Bigloo's support for threads (pthreads or java threads), efficiently implementing Guile's futures and parallel forms is definitely possible. As mentioned in the Guile documentation, the most obvious implementation would be to introduce a threadpool abstraction and
> build the futures and parallel-forms on top of that. Manuel created a similar abstraction for his hop executors. See https://github.com/manuel-serrano/hop/blob/master/src/queue_scheduler.scm.  Taking a look at Java's ThreadPoolExecutor abstraction may also be helpful.
>
> I think this would be an interesting project and would be willing to contribute to it.
>
> Best Regards,
> Joseph Donaldson.
>
> On Wednesday, August 5, 2020, 3:04:46 AM PDT, Sven Hartrumpf <[email protected]> wrote:
>
> Dear Bigloo users.
>
> I read about futures in Guile (see https://www.gnu.org/software/guile/manual/html_node/Futures.html)
> and the parallel forms built on-top, e.g. parallel, par-map and par-for-each
> (see https://www.gnu.org/software/guile/manual/html_node/Parallel-Forms.html).
>
> They look very promising,
> especially because 8, 16 or more CPU cores are available on more and more
> standard CPUs.
>
> Can these constructs be efficiently implemented in Bigloo, too?
>
> Greetings
> Sven