On Thu, May 19, 2005 at 03:31:30PM +0200, Blaisorblade wrote:
> > Why? What does "&sig + 1" mean?
> I think that's because sig is on the stack, and &sig + 1 points to the datas
> saved by the kernel when entering the signal handler, i.e. the registers of
> the caller, saved to be restored on retu
On Thursday 19 May 2005 11:57, Alex LIU wrote:
> On May 18, 2005 9:31 PM, Jeff wrote:
> >> But P and Q are different threads and they will be scheduled
> >> differently,right?
> > No, they're two different ways of looking at the same thread. They're
> > scheduled somewhat differently, but that's
On May 18, 2005 9:31 PM, Jeff wrote:
>> But P and Q are different threads and they will be scheduled
>> differently,right?
> No, they're two different ways of looking at the same thread. They're
> scheduled somewhat differently, but that's just reflecting the two ways of
looking at it. If it'
On Wed, May 18, 2005 at 06:04:31PM +0800, Alex LIU wrote:
> But P and Q are different threads and they will be scheduled
> differently,right?
No, they're two different ways of looking at the same thread. They're
scheduled somewhat differently, but that's just reflecting the two ways
of looking a
On May 17, 2005 11:54 PM, Jeff Dike wrote:
>> In UML,when the kernel_thread was called,the UML kernel thread P will
>> be created in copy_process. And the corresponding host thread Q will
>> be create in copy_thread_tt. Then the host thread Q will run its
>> SIGUSR1 signal handler new_thread_ha
On Tue, May 17, 2005 at 05:38:21PM +0800, Alex LIU wrote:
> In UML,when do_fork was called,the new process P will be created in UML. Then
> in copy_thread_tt(in fact in start_fork_tramp)the corresponding process Q
> will be created in the host linux. I know the pid of the corresponding host
> pr
