Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cysignals is not thread-safe #21

Open
jdemeyer opened this issue Feb 17, 2016 · 7 comments
Open

cysignals is not thread-safe #21

jdemeyer opened this issue Feb 17, 2016 · 7 comments

Comments

@jdemeyer
Copy link
Collaborator

It would be nice if cysignals would support multi-threading. This would be useful for use with Python's threading module or with Cython's parallel features.

@jdemeyer
Copy link
Collaborator Author

Interesting read: http://www.dabeaz.com/python/GIL.pdf

@embray
Copy link
Collaborator

embray commented Apr 21, 2017

I'd be interested in helping to work on this. I've spent some time in Python's threading code, though really that's less important than just getting it right at the C level.

@jdemeyer
Copy link
Collaborator Author

The problem is that I want the following properties:

  1. Correctness
  2. Portability
  3. Speed

This is a classic case of "pick any two" (the current implementation has properties 2 and 3).

@embray
Copy link
Collaborator

embray commented Apr 21, 2017

Right. For a multi-threaded approach I suspect what we're really going to have to have are just completely separate implementations that can be enabled/disabled at compile time and/or runtime.

@jdemeyer
Copy link
Collaborator Author

jdemeyer commented Mar 6, 2019

I'd like to focus on the case where there is a single thread in Python, but possibly multiple threads in the code guarded by sig_on(). This is probably the most typical use case for cysignals.

@dimpase
Copy link
Member

dimpase commented Apr 27, 2020

Apparently on FreeBSD one cannot link cysignals against multithreaded Pari, it just does not work,
see https://trac.sagemath.org/ticket/28242#comment:48

[cysignals-1.10.2]     cc -pthread -shared -L/usr/local/lib -fstack-protector-strong -L/usr/ports/math/sage/work/stage/usr/local/lib -Wl,-rpath,/usr/ports/math/sage/work/stage/usr/local/lib -L/usr/local/llvm90/lib -L/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9 -B/usr/local/bin -L/usr/local/lib -fstack-protector-strong -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -DLIBICONV_PLUG -I/usr/local/include -isystem /usr/local/include -Wp,-U_FORTIFY_SOURCE build/temp.freebsd-12.1-STABLE-amd64-3.7/build/src/cysignals/signals.o -L/usr/local/lib -lpython3.7m -o build/lib.freebsd-12.1-STABLE-amd64-3.7/cysignals/signals.so -lpari -lomp -pthread -L/usr/local/lib
[cysignals-1.10.2]     /usr/local/bin/ld: PARI_SIGINT_block: TLS definition in /usr/local/lib/libpari.so section .tbss mismatches non-TLS reference in build/temp.freebsd-12.1-STABLE-amd64-3.7/build/src/cysignals/signals.o
[cysignals-1.10.2]     /usr/local/bin/ld: /usr/local/lib/libpari.so: error adding symbols: bad value

@kliem
Copy link

kliem commented Jan 31, 2021

I opened issue 122 before checking this. It turns out that struct_signals.h won't even compile with -fopenmp in some instances.

While sig_on()/sig_off() isn't thread safe, I didn't notice any problem with sig_check().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants