public inbox for linux-doc@vger.kernel.org
 help / color / mirror / Atom feed
From: "Nícolas F. R. A. Prado" <nfraprado@protonmail.com>
To: Jonathan Corbet <corbet@lwn.net>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	lkcamp@lists.libreplanetbr.org, andrealmeid@collabora.com
Subject: Re: [PATCH v2 5/5] docs: automarkup.py: Allow automatic cross-reference inside C namespace
Date: Mon, 02 Nov 2020 15:33:09 +0000	[thread overview]
Message-ID: <C6SV6B4N81VS.2IDXIL452NF5N@ArchWay> (raw)
In-Reply-To: <20201014131900.1137cdc8@lwn.net>

On Wed Oct 14, 2020 at 4:19 PM -03, Jonathan Corbet wrote:
>
> On Wed, 14 Oct 2020 11:56:44 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
> > > To make the first step possible, disable the parallel_read_safe option
> > > in Sphinx, since the dictionary that maps the files to the C namespaces
> > > can't be concurrently updated. This unfortunately increases the build
> > > time of the documentation.
> >
> > Disabling parallel_read_safe will make performance very poor.
> > Doesn't the C domain store the current namespace somewhere?
> > If so, then, instead of using the source-read phase, something
> > else could be used instead.

The issue is that C domain parsing happens at an earlier phase in the Sphinx
process, and the current stack containing the C namespace is long gone when we
get to do the automatic cross-referencing at the doctree-resolved phase.

Not only that, but the namespace isn't assigned to the file it's in, and
vice-versa, because Sphinx's interest is in assigning a C directive it is
currently reading to the current namespace, so there isn't any point in saving
which namespaces appeared at a given file. That is exactly what we want, but
Sphinx doesn't have that information.

For instance, printing all symbols from app.env.domaindata['c']['root_symbol']
shows every single C namespace, but the docname field in each of them is None.

That's why the way to go is to assign the namespaces to the files at the
source-read phase on our own.

> That seems like the best solution if it exists, yes. Otherwise a simple
> lock could be used around c_namespace to serialize access there, right?

Actually I was wrong when I said that the issue was that "they can't be
concurrently updated". When parallel_read_safe is enabled, Sphinx spawns
multiple processes rather than multiple threads, to get true concurrency by
sidestepping python's GIL. So the same c_namespace variable isn't even
accessible across the multiple processes.

Reading multiprocessing's documentation [1] it seems that memory could be shared
between the processes using Value or Array, but both would need to be passed to
the processes by the one who spawned them, that is, it would need to be done
from Sphinx's side.

So, at the moment I'm not really seeing a way to have this information be shared
concurrently by the python processes but I will keep searching.

Thanks,
Nícolas

[1] https://docs.python.org/3/library/multiprocessing.html#sharing-state-between-processes


      reply	other threads:[~2020-11-02 15:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 23:13 [PATCH v2 0/5] docs: automarkup.py: Make automarkup ready for Sphinx 3.1+ Nícolas F. R. A. Prado
2020-10-13 23:13 ` [PATCH v2 1/5] docs: automarkup.py: Use new C roles in Sphinx 3 Nícolas F. R. A. Prado
2020-10-30 13:33   ` Dafna Hirschfeld
2020-10-30 14:00     ` Jonathan Corbet
2020-10-30 14:10     ` Python 2.7 support and automarkup.py - Was: " Mauro Carvalho Chehab
2020-10-30 14:14       ` Jonathan Corbet
2020-10-30 14:15         ` Mauro Carvalho Chehab
2020-10-30 14:39         ` Matthew Wilcox
2020-10-13 23:13 ` [PATCH v2 2/5] docs: automarkup.py: Fix regexes to solve sphinx 3 warnings Nícolas F. R. A. Prado
2020-10-14 19:11   ` Jonathan Corbet
2020-10-13 23:13 ` [PATCH v2 3/5] docs: automarkup.py: Skip C reserved words when cross-referencing Nícolas F. R. A. Prado
2020-10-13 23:13 ` [PATCH v2 4/5] docs: automarkup.py: Add cross-reference for parametrized C macros Nícolas F. R. A. Prado
2020-10-13 23:13 ` [PATCH v2 5/5] docs: automarkup.py: Allow automatic cross-reference inside C namespace Nícolas F. R. A. Prado
2020-10-14  9:56   ` Mauro Carvalho Chehab
2020-10-14 19:19     ` Jonathan Corbet
2020-11-02 15:33       ` Nícolas F. R. A. Prado [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C6SV6B4N81VS.2IDXIL452NF5N@ArchWay \
    --to=nfraprado@protonmail.com \
    --cc=andrealmeid@collabora.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkcamp@lists.libreplanetbr.org \
    --cc=mchehab+huawei@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox