0

It is a short question. I believe there is no way to cancel a job submitted to libclang through python bindings (for example code completion task).

Can anybody prove me wrong? I am interested in using libclang in a multi threaded environment but it seems it is intended to be accesses from single thread only. If there is also no mechanism to cancel tasks, then one has to wait till the task finishes even if the results are not needed anymore. Does anybody have any ideas on how to overcome this?

niosus
  • 738
  • 8
  • 22
  • libclang is not a work queue, so I'm not sure what kind of "job" or "task" you are referring to. – xaxxon Oct 28 '16 at 23:37
  • Sorry for being imprecise. What I mean is just calling functions through libclang python bindings. I call them tasks here to stress that I would like to call them concurrently. Let's even only focus on code completion for now. So assume that I have a translation unit and I run code completion function on it. – niosus Oct 28 '16 at 23:40
  • making concurrent calls and cancelling such things doesn't sound like something libclang would be involved with. Of course if libclang isn't threadsafe then none of that really matters, but if that's all you need, you should ask that specific question. – xaxxon Oct 29 '16 at 02:59

1 Answers1

1

[..] it seems it is intended to be accesses from single thread only.

I don't have anything that clearly backs this, but as the documentation nowhere even talks about thread safety I think all of libclang should be considered not thread safe.

But: Seeing that basically everything libclang does is (indirectly) bound to an CXIndex I would guess that you could have a CXIndex per thread and then use those (or anything that's created from them) in parallel (but not "share" anything between threads).

If there is also no mechanism to cancel tasks, then one has to wait till the task finishes even if the results are not needed anymore. Does anybody have any ideas on how to overcome this?

The "safe" solution is to move all libclang related code into a dedicated process. From your main application you then start (or kill) these processes (using OS dependent mechanisms) as you like. This is, of course, "heavy" in terms of both performance (starting processes) and development effort (serializing communication between processes).

The alternative is to hope (or verify in the source code) that the libclang devs keep all data associated to a CXIndex and thus don't introduce possible data races in their code. Then you can give every thread its own index, its own translation units etc. When you have a "job", you launch a thread (or reuse one) to work on it. If in the mean time the results are no longer needed, then you just discard the results when (if) they ever get ready.

Daniel Jour
  • 15,896
  • 2
  • 36
  • 63