>The biggest problem is having this working (and claim as supported)
>amongst the huge number of compilers and platforms that PCRE2 runs on.
>That's not an easy task.
this is exactly my problem :)
Perhaps we could start by supporting some platforms, and gradually cover more
with the community help. I heard that asm volatile forces GCC (and perhaps
clang) to disable moving instructions around such asm blocks.
E.g:
statement1;
asm volatile (" ");
statement2;
Is it true, that statement1 is fully completed before statement2 is executed
even if the assembly part is nothing?
Hence:
ptr->member = something;
asm volatile (" ");
result_ptr->member = ptr;
is executed in-order?
The CPU can still reorder stores. An x86 CPU does not have (need) data write
barrier instruction as far as I know. Recent ARM 32 CPUs has data write
barrier. Could somebody tell me how can I test whether this instruction is
available at compile time? ARM 64 should not be a problem. I have not checked
other CPUs yet.
There is one more thing. This theoretically affects everything, not just JIT
compilation. If we compile a pattern with pcre2_compile, it is possible that
the result pointer has been shared with another thread, but the compiled
pattern data is not.
Main thread:
compiled_pcre_pattern->byte_code = something;
return compiled_pcre_pattern;
shared_pattern = compiled_pcre_pattern;
Another thread:
match (shared_pattern, subject);
The byte_code part can be a garbage on the other thread (since it can be
executed by another CPU). People did not complain about these effects before,
is there a reason for that? I don't want to solve a non-existing problem.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
