Re[2]: Cygwin 1.1.0 gdb troubles

[Paul Sokolovsky <paul-ml@is.lg.ua>]

Hello Christopher,

Christopher Jones <cbjones@nortelnetworks.com> wrote:

CJ> Seems like it would make more sense to at least hide these cygwin pids and
CJ> let users always use windows pids for ps, kill, $$ in a shell, etc.  So the
CJ> PID and PPID values would be the real windows values and cygwin pids would
CJ> disappear into the internals somewhere... probably a lookup table if you
CJ> really need to have them still.  Something like this would be more seemless,
CJ> wouldn't it?

    If no cygwin people will agree with you, then at least me will.
IMHO, win32 is undoubtfully POSIX by spirit, only having somewhat
twisted upbringing. Almost any POSIX feature maps one-to-one to win32
one and difference is only in some idiosyncratic details. As an
example, DeleteFile() does exactly what remove() does with one
difference: remove() explicitly states possibility of removing opened
file, while DeleteFile() explicitly prohibits it. I can't believe
there's some adequate reasoning behind DeleteFile()'s behaviour. I
just can imagine some win32 architect reading POSIX spec and time to
time exclaiming: 'And *here*, we'll do vice-versa!' ;-)

     Well, what idiosyncratic features of native pids would harden
their usage as POSIX pisd as-is?

1. While NT's pids are rather POSIX-correct as-is, 9x's ones are
negative values, large (up to 10 dec digits) by module.
2. There's no documented way to get ppid on NT.
3. It's impossible to overlay image of current process. This means,
when performing usual fork-exec chain, there will be three processes:
parent, exec() implementer stub and execed child. So, between child
and parent in POSIX terms there will be other process.

    While these problems may seem denying original idea, they hardly
do. The workarounds for them exist, working and confidently may be
called more robust than maintaining additional superstructures,
moreover shared between all processes.

    Well, *that*'s not most annoying feature of cygwin. Just net
version ago there might arise problems with just having cygwin work
properly after installation, mostly because ungrounded default mount
table setup. But look - this version now takes care to ask user where
he wants having root mount. So, all consistently improving and maybe
one day other areas also will be addressed.


CJ> Brian




--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com