Hi, experts.
I want to test whether (third library) function (say X) is interruptible or not.
For this, I want to create two threads one for calling function X, the other for interrupting (sending signal) to the first one while it's inside the function X. But I don't know the exact time to interrupt.
Since X, is library function I can't change it in any way.

Is there any kind of ideas regarding this interesting problem?

Thanks.

What you describe happens all the time with almost every function, and it isn't a problem.

Perhaps you mean the alternative of where T2 tries to call X(), while T1 is already in X().
That's re-entrancy, and is a far more interesting problem.

And no, you can't just "test" to see if a function is re-entrant by calling it a bunch of times from two threads, and seeing what happens.

Hi,
Thanks for you quick reply.
I think I couldn't explain my problem correctly.
T1 is calling X(), I want to send a signal to T1 when it's inside the function X(), not before calling it nor after calling it. So my objective is to test whether I'm able to receive signals inside X() or not. Even if this is always the case (it's always possible to receive the signal), which I believe is not, I want just to be able to interrupt T1 exactly inside X(). The only purpose of T2 is to send signal to T1 while T1 is inside X(). Besides that T2 doesn't have to do anything.
I hope I'm more clear now.

Thanks.

ok :)
the problem is that I can't solve it even algorithmically/theoretically- so I've not "tried" it. Algorithmically, I can NOT determine how can I signal/interrupt exactly inside the function X().

I'm going to use posix threads to solve this.

Unless X() takes a substantial amount of time to execute, it's going to be hard to time a signal.

But something like this for T1 (in a loop)
- release semaphore
- call X()
- get semaphore

And for T2 (in a loop)
- get semaphore
- generate signal
- release semaphore

But if you've got a dual-core machine and an OS that can really distribute threads over processors, then it might produce some results.

Unless X() takes a substantial amount of time to execute, it's going to be hard to time a signal.

But something like this for T1 (in a loop)
- release semaphore
- call X()
- get semaphore

And for T2 (in a loop)
- get semaphore
- generate signal
- release semaphore

But if you've got a dual-core machine and an OS that can really distribute threads over processors, then it might produce some results.

I have thought about the way you proposed earlier. But this way does NOT guarantee that I'll signal T1 inside X(). Unfortunitly, we can't make any assumptions about the time spent by X();

How about following solution:
I don't know the properties of pthread_attr_t, but is it possible to solve this problem by the help of pthread_attr_t? What I mean is, let T1's start routine to be X() and tell by the help of attr1 to spend much time or don't exit inside the X().

main(){
....
pthread_create (T1,attr1,X,arg)
pthread_create (T2,attr,start_routine,arg)
....
}

This article has been dead for over six months. Start a new discussion instead.