code review 7565048: runtime: refactor os-specific code

runtime: refactor os-specific code

thread_GOOS.c becomes os_GOOS.c.

signal_GOOS_GOARCH.c becomes os_GOOS_GOARCH.c,
but with non-GOARCH-specific code moved into os_GOOS.c.

The actual arch-specific signal handler moves into signal_GOARCH.c
to avoid per-GOOS duplication.

New files signal_GOOS_GOARCH.h provide macros for
accessing fields of the very system-specific signal info structs.

Lots moving, but nothing changing.
This is a preliminarly cleanup so I can work on the signal
handling code to fix some open issues without having to
make each change 13 times.

Tested on Linux and OS X, 386 and amd64.
Will fix Plan 9, Windows, and ARM after the fact if necessary.
(Plan 9 and Windows should be fine; ARM will probably have some typos.)

Net effect: -1081 lines of code.

[rsc, 2013-03-14 18:31:29]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg

[r, 2013-03-14 18:34:12]

LGTM

[rsc, 2013-03-14 18:35:17]

*** Submitted as https://code.google.com/p/go/source/detail?r=9d23267675ef ***

runtime: refactor os-specific code

thread_GOOS.c becomes os_GOOS.c.

signal_GOOS_GOARCH.c becomes os_GOOS_GOARCH.c,
but with non-GOARCH-specific code moved into os_GOOS.c.

The actual arch-specific signal handler moves into signal_GOARCH.c
to avoid per-GOOS duplication.

New files signal_GOOS_GOARCH.h provide macros for
accessing fields of the very system-specific signal info structs.

Lots moving, but nothing changing.
This is a preliminarly cleanup so I can work on the signal
handling code to fix some open issues without having to
make each change 13 times.

Tested on Linux and OS X, 386 and amd64.
Will fix Plan 9, Windows, and ARM after the fact if necessary.
(Plan 9 and Windows should be fine; ARM will probably have some typos.)

Net effect: -1081 lines of code.

R=golang-dev, r
CC=golang-dev
https://codereview.appspot.com/7565048

[akumar_mail.nanosouffle.net, 2013-03-15 19:59:16]

On 14 March 2013 11:35,  <rsc@golang.org> wrote:
> The actual arch-specific signal handler moves into signal_GOARCH.c
> to avoid per-GOOS duplication.

However, this is still only built for UNIX systems, so the name
seems to be inconsistent with the general naming scheme.
Since the entire signal handling code for Plan 9 and Windows
has been moved into os_GOOS_GOARCH.c files respectively,
perhaps even signal_GOARCH.c should become
os_unix_GOARCH.c? Otherwise, I'd suggest at least
signal_unix_GOARCH.c.

> New files signal_GOOS_GOARCH.h provide macros for
> accessing fields of the very system-specific signal info structs.

Also, these might be better merged into defs_GOOS_GARCH.h,
in line with the former approach outlined above.

[rsc, 2013-03-15 20:31:32]

On Fri, Mar 15, 2013 at 3:58 PM, Akshat Kumar
<akumar@mail.nanosouffle.net>wrote:

> On 14 March 2013 11:35,  <rsc@golang.org> wrote:
> > The actual arch-specific signal handler moves into signal_GOARCH.c
> > to avoid per-GOOS duplication.
>
> However, this is still only built for UNIX systems, so the name
> seems to be inconsistent with the general naming scheme.
> Since the entire signal handling code for Plan 9 and Windows
> has been moved into os_GOOS_GOARCH.c files respectively,
> perhaps even signal_GOARCH.c should become
> os_unix_GOARCH.c? Otherwise, I'd suggest at least
> signal_unix_GOARCH.c.
>

Thanks for the feedback, but we've met our refactoring quota for a few
months. Let's leave things the way they are now. Perhaps some day I will
make Plan 9 and Windows use those files too, but for now I am comfortable
with 386+amd64+arm+plan9/386+plan9/amd64+windows/386+windows/amd64. I can
deal with the 5x duplication a lot better than I can deal with the 17x we
had a few days ago.

> New files signal_GOOS_GOARCH.h provide macros for
> > accessing fields of the very system-specific signal info structs.
>
> Also, these might be better merged into defs_GOOS_GARCH.h,
> in line with the former approach outlined above.
>

The defs files are automatically generated. Hand-written code cannot be
placed there. It is also useful to limit the number of files that see those
definitions.

Russ