New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix signal handler #4
Comments
I intentionally check it after each loop so an image doesn't get half printed I'm going to add an option for the number of loops so that line will be needed |
The reuse of this data type is one of the preferred ways for the portable data exchange with your signal handler. How do you think about to improve software portability a bit here? An other software design option would be to delegate signal handling or the image file processing to another thread, wouldn't it? |
ok for the portability. Having multiple threads for catimg just to handle the sigterm or any other signal is overkill, don't you think 😅 |
It depends on user expectations for your software application. In which time frame would you like to see the appropriate response for the event "SIGINT"? |
Well, nobody complained about it yet.
At the end of an image/frame for a GIF and anytime for a normal image. Although this may vary on the terminal size. I guess I'll etablish a pixel count. I'll run some test and call the handler after that many pixels are displayed |
Is such an approach really needed? |
nope, as I said in the first comment |
I assume that there are users who will not like delayed signal handling. Can the portable data type "sig_atomic_t" be applied at least? |
I'll see, thanks 😄 |
sig_atomic_t
" should be reused for the variable "stop".loops = loop
" be deleted?The text was updated successfully, but these errors were encountered: