[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] ob-async
From: |
Nicolas Goaziou |
Subject: |
Re: [O] ob-async |
Date: |
Sun, 26 Feb 2017 16:46:15 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hello,
Alex Bennée <address@hidden> writes:
> Ken Mankoff <address@hidden> writes:
>
>> An RSS feed I follow mentioned ob-async here:
>> https://github.com/astahlman/ob-async
>>
>> I haven't seen it mentioned on the list yet. Perhaps others would be
>> interested in asynchronous Babel processing. I've seen the feature
>> requested often on this list.
>
> This is not the first attempt to my knowledge. I know of:
>
> - my hacky attempt https://github.com/stsquad/async-org-babel
> - John Kitchen's python specific version
> http://kitchingroup.cheme.cmu.edu/blog/2015/11/20/Asynchronously-running-python-blocks-in-org-mode/
> - this matlab version
> http://emacs.stackexchange.com/questions/21301/async-execution-in-org-babel
>
> So I think there have been enough proof of concepts of using async.el
> and inserting results at a later date. I think what would be really
> useful is some feedback from the org-mode maintainers about the various
> approaches and if something generic could be included with org-mode
> itself.
>
> Any thoughts?
I never used any of these, so please take this with a grain of salt.
AFAIU, these solutions are too limited at the moment. They suffer from
the same problem as current ":cache" parameter, i.e., they seem unable
to cope with blocks that refer and execute other blocks.
IMO, for anything serious, we need to implement something that is able
to capture the "closure" of a block. In this case, all blocks belonging
to that closure would be marked as read-only during the process, so as
to avoid race conditions. We also need to be able to retrieve all the
results from all the blocks involved.
Regards,
--
Nicolas Goaziou