From: Shinobu M. <con...@ya...> - 2010-07-19 11:09:48
|
I recently needed to implement sigaction, SIGALRM and some related stuff, as discussed here: https://sourceforge.net/tracker/?func=detail&aid=3031260&group_id=168561&atid=847238 Although I'm not smitten by the delusion that such code could go into the MinGW codebase as is, I thought you might still find it interesting enough to have a look at it. Note: I originally posted on the tracker over there to get some feedback first, but after some nosing around I came to realise that it's unlikely I'll obtain a reaction there. |
From: Earnie <ea...@us...> - 2010-07-19 12:07:11
|
Shinobu Maehara wrote: > I recently needed to implement sigaction, SIGALRM and some related stuff, as > discussed here: > https://sourceforge.net/tracker/?func=detail&aid=3031260&group_id=168561&atid=847238 > > > Although I'm not smitten by the delusion that such code could go into the MinGW > codebase as is, I thought you might still find it interesting enough to have a > look at it. > Note: I originally posted on the tracker over there to get some feedback first, > but after some nosing around I came to realise that it's unlikely I'll obtain a > reaction there. > Isn't sigaction POSIX? You know the runtime is ANSI only, correct? We do however, have an extension to the Microsoft runtime that does include some POSIX. If you want to submit a patch for us to consider then please refer to http://www.mingw.org/wiki/SubmitPatches for instructions. -- Earnie -- http://www.for-my-kids.com |
From: Shinobu M. <con...@ya...> - 2010-07-24 02:43:11
|
> Isn't sigaction POSIX? You know the runtime is ANSI only, correct? No, I didn't. But now I've looked that up, and dug some more, I see that the signal values are the same as VC++ and resemble the ones in Minix or Linux: Minix (1-8):HUP INT QUIT ILL TRAP ABRT BUS FPE Linux (1-8):HUP INT QUIT ILL TRAP ABRT UNUSED FPE MinGW (1-8):[ 1 ]INT [ 3 ]ILL [ 5 ][ 6 ][ 7 ]FPE Minix (9-15):KILL USR1 SEGV USR2 PIPE ALRM TERM Linux (9-15):KILL USR1 SEGV USR2 PIPE ALRM TERM MinGW (9-15):[ 9 ][ 10 ]SEGV [ 12 ][ 13 ][ 14 ]TERM BREAK is WINCH in Minix and TTIN in Linux. I can't know why. ABRT is BREAK + 1. I assume that whoever added this didn't know about the history of the numbers and just added it to the end in much the same fashion as I did. Too late to change that now, or else you will break compatibility with VC++. That does mean however, that I should have inserted ALRM before TERM. > We do however, have an extension to the Microsoft runtime that does include some POSIX. If you want to submit a patch for us to consider then please refer to http://www.mingw.org/wiki/SubmitPatches for instructions. I can't seem to find that right now, and I would have to see it to be able to make a judgement on a suggestion on how to include something like this. Maybe I'm just looking in the wrong place? Is it a separate project? Also, maybe I should get someone with more Posix experience to get a good critical look at things. For example, what if someone were to call sigaction inside a masked signal handler? I think my code would result in the wrong behaviour as is, but I could be wrong. The documentation on www.opengroup.org isn't always that clear on the exact semantics of things. Another example: should the mask change always be atomic? |
From: Tor L. <tm...@ik...> - 2010-07-24 15:09:30
|
> No, I didn't. But now I've looked that up, and dug some more, I see that the > signal values are the same as VC++ and resemble the ones in Minix or Linux: Umm, what does the numeric values of the SIG* signals have to do with anything? It is, well not a coincidence, but just laziness, if they happen to be the same in different implementations. Trying to implement POSIX signal handling on Windows in a program that uses the Microsoft C runtime is just pointless. Windows is not POSIX, and the C runtime doesn't try to make it behave like POSIX. --tml |
From: Shinobu M. <con...@ya...> - 2010-07-25 00:46:03
|
Tor Lillqvist citing me: > > No, I didn't. But now I've looked that up, and dug some more, I see that the > > signal values are the same as VC++ and resemble the ones in Minix or Linux: If this sentence somehow made you think that I was using the value correspondence as an argument to insert full POSIX signals into the general ANSI runtime, I apologise. To clarify, the "No I didn't." was meant as a "sorry". The whole rest of the message was kind of in reply to this line by Earnie: > We do however, have an extension to the Microsoft runtime that does include >some POSIX. Whether the actual signal values matter, well, I don't know who would write software that will pass signal values around, much less between objects compiled with different compilers, but I see no good reason to be different. It could be possible that using different signal values would come to bite someone in the ass in some future unforeseen circumstance, could it not? So, in short, I apologise for the confusion and do not advocate including this in a runtime that aims to be strictly ANSI, since that would be wrong. |