> It seems that the signal reception in exiting process logic has
changed.
> Serial depends on the old behaviour and its difficult to see how it
> should be fixed and what else would be "correct behaviour" here.
> Alan
Hi Alan,
That's what I was wondering.
Thanks for confirming it.
Do you know if there was any particular reason why it was changed that
signals can't be delivered to an exiting process in 2.6?
Was there maybe some sort of race, and this was the best way to resolve
it?
Using "setserial" to set a timeout value to bail is just "not right".
In most cases, people do NOT want the data to be tossed away after
the timeout expires.
Imagine a printer stuck in a hardware flow control state because the
printer ran out of paper.
The user would end up losing the tail end of their print job!
Setting a infinite timeout value with setserial is also bad.
Without being able to take a 2nd+ signal, the port ends up being stuck
forever.
Only a reboot, or a reassertion of CTS would "fix" it.
Scott
> Do you know if there was any particular reason why it was changed that
> signals can't be delivered to an exiting process in 2.6?
> Was there maybe some sort of race, and this was the best way to resolve
> it?
I have no idea. It may be a change due to the threaded signal support.
Ask whoever hacked up the signal code last I guess.