Re: Accessing Physical Memory & Other Process's Address Space

Gil Hamilton <spamtrap@xxxxxxxxxx> wrote:
Tim Roberts <spamtrap@xxxxxxxxxx> wrote:

Windows does have kernel-mode threads, but in Windows a "thread" and a
"process" are very different things. In Linux, the line between those
two concepts is rather fuzzy.

I don't really buy that. Would you explain what differences you see? As I
see it, while the mechanisms for creating processes and threads are
significantly different in the two systems, they share almost every
important conceptual attribute: The process represents those things that
can be shared among multiple threads: process ID, executable code, virtual
address space, open file descriptors, and so forth.

Well, perhaps my knowledge is out of date. The last time I looked into it,
threads in Linux were essentially implemented as a special case of
processes. That is, creating a thread basically did a lightweight process
creation.

The thread represents
an execution context and hence has a stack in user-mode representing its
context in user mode (and a kernel stack representing its context there).

In the traditional Unix concept, it is the process that has an execution
context and a stack, and my (possibly long outdated) understanding was that
threads simply inherited that.

Creating a process in linux with fork(2) simply creates a process with a
single unnamed thread implicitly attached to it.

Does it? Again, I thought each thread in the current Linux implementation
had its own process ID, so that creating a thread was not very much
different from a vfork(2).

I think it's slightly
more explicit in Windows -- IIRC, at the lowest level NtCreateThread must
be called to create the execution context before the process created by
NtCreateProcess can do anything -- but in the end, it's in the same thing.
In fact, ordinary programs just call CreateProcess, which creates both
process and thread. It's pretty much exactly equivalent to fork + exec.

I don't think that's an accurate assessment. In Windows, the process is
really just a container for memory and threads. A process is created and
assigned memory, and threads are created within it. In Linux, each thread
is essentially a mini-process.

Or so I thought.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.

.

Relevant Pages

  • Re: OT : Recommendations for Dell battery supplier
    ... it matters in the present context, but yes it is Vista because I can't be there to teach her linux and she used Windows in the past. ...
    (uk.comp.os.linux)
  • OT : Recommendations for Dell battery supplier
    ... it matters in the present context, but yes it is Vista because I can't be ... there to teach her linux and she used Windows in the past. ...
    (uk.comp.os.linux)
  • Re: APL is Alive & Well V/S APL Needs to learn
    ... The standard Dyalog APL is shipped on Windows Mobile, Windows, ... Linux, Solaris and AIX, in 64-bit versions where the OSes support it. ... different Unix systems over the last 25 years. ... I'm not sure what "language definition" means in this context, ...
    (comp.lang.apl)
  • Re: context-menu on mouse-down
    ... I've been thinking of buying a Mac, and may be this will do in the future. ... a context menu is displayed asking you what to do. ... One thing I like in Linux is that it will let you use your favourite look ... It supports Windows, ...
    (microsoft.public.windowsxp.customize)
  • Re: Future of IT in Lebanon
    ... working knowledge of Indian programmers DNA, nor of their intuitive Java ... > So Longhorn is not an experiment and Linux is an experiment? ... another chapter in the Windows story, and the Microsoft marketing machine is ... > application opens, Check the about, it says Microsoft Visual Basic 6.3. ...
    (soc.culture.lebanon)