Switch map to sync.Map to make it safe in multi-thread application?
spacewander opened this issue · comments
Currently, libcoraza uses map to store the states:
Line 42 in 23b4abd
map is not thread-safe, if we want to use libcoraza in a multi-thread C/C++ application, it would be better to switch to sync.Map.
Compared with the whole operation, the extra cost from the sync.Map is acceptable. And seems the use cases in libcoraza satisfy "a given key is only ever written once but read many times" so it may be better than using extra sync.RWMutex.
More info can be found in https://pkg.go.dev/sync#Map
CGO is not yet compatible with multithreaded programming, which may cause deadlock.
I've ported libcoraza to openresty successfully.
Nice to hear some ideas.
CGO is not yet compatible with multithreaded programming, which may cause deadlock.
Are there any more details?
I've ported libcoraza to openresty successfully.
Would you compare this with nginx + modsecurity? What's the advantage?
libcoroza is easy to develop . I've developed a log4j module for detecting more evasive exploit.But porting to libmodsecurity is hard. Learning C++ is quite challenging.
performance
I guess it's because the Go's threads disappear after the Nginx calls fork. Loading the Go shared lib in the init_worker phase may solve this problem.
libcoroza is easy to develop . I've developed a log4j module for detecting more evasive exploit.But porting to libmodsecurity is hard. Learning C++ is quite challenging.
I am glad to hear that.
sure loading the
Go shared library in init-worker phrase can resolve problem.I've completed openresty lua module. I want to merge into apisix.How should I do
You can open an issue there and discuss with them.
