Hi Michael, On Wed, 2009-03-18 at 06:58 +1300, Michael Kerrisk wrote: > 2009/3/17 Subrata Modak <[email protected]>: > > Hi Gábor, > > > > On Mon, Mar 16, 2009 at 3:36 AM, Gábor Melis <[email protected]> wrote: > >> > >> On Domingo 15 Marzo 2009, Oleg Nesterov wrote: > >> > On 03/15, Gábor Melis wrote: > >> > > On Domingo 15 Marzo 2009, Oleg Nesterov wrote: > >> > > > If test_signal (SIGUSR1) is blocked, this means it is already > >> > > > delivered, and the handler will be invoked when we return from > >> > > > sigsegv_handler(), please see below. > >> > > > >> > > SIGUSR1 is delivered, its sigmask is added to the current mask but > >> > > the handler is not yet invoked and in this instant synchronous > >> > > sigsegv is delivered, its handler invoked? > >> > > >> > Can't understand the question. Could you reiterate? > >> > >> No need, my question was answered below. > >> > >> > > > When sigprocmask(SIG_UNBLOCK) returns, both signals are > >> > > > delivered. The kernel deques 1 first, then 2. This means that the > >> > > > handler for "2" will be called first. > >> > > > >> > > My mental model that matches what I quickly glean from the sources > >> > > (from kernel/signal.c, arch/x86/kernel/signal_32.c) goes like this: > >> > > > >> > > - signal 1 and signal 2 are generated and made pending > >> > > - they are unblocked by sigprocmask > >> > > - signal 1 is delivered: signals in its mask (only itself here) are > >> > > blocked > >> > > >> > yes. > >> > > >> > the kernel changes ip (instruction pointer) to sig_1. > >> > > >> > > its handler is invoked > >> > > >> > no. > >> > > >> > We never return to user-space with a pending signal. We dequeue > >> > signal 2 too, and change ip to sig_2. > >> > > >> > Now, since there are no more pending signals, we return to the user > >> > space, and start sig_2(). > >> > >> I see. I guess in addition to changing the ip, the stack frobbing magic > >> arranges that sig_2 returns to sig_1 or some code that calls sig_1. > >> > >> >From the point of view of sig_2 it seems that sig_1 is already invoked > >> because it has its sigmask in effect and the ip in the ucontext of > >> sig_2 points to sig_1 as the attached signal-test.c shows: > >> > >> sig_1=80485a7 > >> sig_2=80485ed > >> 2 1 > >> eip: 80485a7 > >> 1 0 > >> eip: b7fab424 > >> > >> The revised signal-delivery-order.c (also attached) outputs: > > > > Our Project does Kernel Testing (http://ltp.sourceforge.net/). I was > > watching this thread and found the discussion interesting. Could you please > > tell us, whether these test programs are dependent on each other, or they > > need to be executed separately to produce 2 different outputs, and then > > compare these outputs for conclusion. With your permission we would like to > > add these tests(under GPL) in to our automated test environment. Could you > > help us here ? > > Subrata, > > I think I understand all the details that Gabor and Oleg are referring > to, but I'm wondering what you hope is testable here. Much of this is > implementation-specific detail. For example, if two signals are > pending, POSIX.1 does not mandate the order in which they are > delivered (unless they are real-time signals). POSIX.1 doesn't even > require that both signals will be delivered. Here the text from the > specification of sigprocmask():
I got it. > > # If there are any pending unblocked signals after > # the call to sigprocmask( ), at least one of those > # signals shall be delivered before the call to > # sigprocmask( ) returns. > > So I'm not sure that Gabor's tests would be useful in LTP. Thanks for explaining the rationale in the test. With contribution(s) to LTP being very less in terms of new tests, i think it is a good idea to look through LKML, if developers are writing some unit test(s), and then evaluate their worthiness to be made part of LTP. I would rather fall back on you guys, who have regular interface to LKML to help me in deciding that. Thanks very much. I would not pursue with this test further. Regards-- Subrata > > Cheers, > > Michael > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Ltp-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ltp-list ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
