sebastianene07 edited a comment on pull request #1009:
URL: https://github.com/apache/incubator-nuttx/pull/1009#issuecomment-626184887


   > > > @sebastianene07 I stop to review the last several patch because it's 
better to reorg your patch into a meaning set. For example, I found serveral 
patch fix the problem in the previous one.
   > > > And basically, the better change is enhance up_oneshot.c which is much 
simple and get the tickless support free:
   > > > 1.Register alarm timer in up_oneshot.c
   > > > 2.Call back to NuttX in signal action
   > > > 3.Modify up_irq_save/up_irq_restore to disable/enable signal
   > > > I don't think it's nessary to use ucontext API.
   > > 
   > > 
   > > I used ucontext API because it can restore the signal mask after a call 
to `swapcontext`. The setjmp/longjmp mechanism doesn't seem to work with 
signals. Do you think it's better to close this PR and re-open a different one 
with the suggested changes ?
   > 
   > But if the irq save/restore work correctly, I think we don't need care 
about the host signal logic. The thread in NuttX isn't 1:1 mapping to host 
thread. The whole NuttX simulator run on one host thread(main thread) except 
you enable SMP then we have multiple threads(same number as Simulated CPUs). 
The context switch inside NuttX doesn't mean we switch host thread. From the 
host view, the thread is still running on the main thread, so I can't 
understand why we need save/restore host signal flag here.
   
   We do need to care about the host signal logic because when we are executing 
the timer signal handler we usually end up altering the signal handler 
execution flow(by doing a longjmp). Altering the execution flow of the signal 
handler without restoring the signal mask may lead to no further events being 
served. 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to