Roger Oberholtzer wrote:
On Mon, Jun 4, 2018 at 11:05 AM, Per Jessen <per@computer.org> wrote:
ah, well. sem_wait() isn't safe to call either, only sem_post(). Should have been obvious, duh.
We used to use signals in our 'real-time' data collection programs. We did, at some point, add threads into the mix. I think the problem is if the signal handler itself has anything at all to do with thread/mutex control. If threads/mutexes and signals are separate, then there is no problem (IMO).
Yes, I'm sure that is correct.
Of course we have eliminated all signal stuff. It was really more appropriate on unicore processors.
I'm using aio, the completion of an operation is signalled with SIGAIODONE. In the signal handler, I had a call to a monitoring function, put some data in a ring buffer. I wanted to lock the getting of a buffer slot with the sem_wait/sem_post. For the time being, I have disabled that monitoring call, but I'll likely replace the sem_wait/sem_post with a busy lock in assembler. -- Per Jessen, Zürich (21.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming+owner@opensuse.org