RFC: concurrent forks of graphics conversions

[Scott Kostyshak]

On Sat, Sep 24, 2022 at 10:06:36PM +0200, Pavel Sanda wrote:
> On Sat, Sep 24, 2022 at 02:11:36PM -0400, Scott Kostyshak wrote:
> > Each iteration of the while loop constructs a new ForkedCall instance.
> > call.startScript() then forks the process.
> 
> I see now, you are right. If I understand the logic now (basically each loop
> iteration triggering new callNext via callback), the problem is sharing
> callQueue_ in between threads and you need to guard the access by some mutex or
> similar. And the same for nforks_current variable and any shared variable
> recursively accessed in stopCaller...
> If I got it right (not necessarily) then also stopCaller is called for each
> iteration loop at the end?

That sounds right. I think it probably makes sense to change the design.
First I want to read about 'nod', which apparently is a library that we
include and use. At some point I saw something about a thread policy. In
any case, I want to study other concurrency designs, ones related to
"consumers" and "producers". It would be nice to avoid the recursion at
least. Maybe use atomic decrements for nforks_current, and find a way
for the "consumer" thread to be the only one that accesses callQueue_,
so it is just a matter of what waiting/polling mechanism is best. I
don't know much about any of this, which is why I wanted to check in
before I jump down the rabbit hole. But in any case, I think this size
of problem is perfect for my lack of experience, since it seems
manageable.

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20220924/72cbb225/attachment.asc>