Roger Fujii wrote:
It *appears* like a process to the user in the ui (ps has separate PIDs). The problem is that words like "process" and "linking" really require some context around them and it's hard to codify that in a document.
Yes.
Perhaps it would be clearer if I said 'address space' instead of 'process'. (IBM is working on a new threading library that will make you happy, I think; it makes use of the "thread group" feature in the 2.4 kernel.)
Don't think it would change all the much. Think what 'address space' means in a NUMA model. 2 threads running in the same address space MAY be running on separate processors with a copy of the address space..
An interesting thought. I'd better sleep on that before commenting.
Or in wine's case, you're going to make a distinction between server dlls and client dlls ONLY because they cross a process boundary?
Yes. A call that crosses an address space boundary by using a remote procedure call protocol is considered remote, and is neither static nor dynamic linking.
So, a windows DLL under windows is neither static nor dynamically linked since the DLLs live in a funky state that is in the 'kernel' process space and not with the app (at least, this is what I remember).
Most windows DLLs are pure userspace and execute in-process, so that's dynamic linking. But a windows DLL that implements an operating system service is explicitly ok to link to, even for (non-L)GPL apps. How that OS linkage is done is moot, as long as it's not static, I think.
If you think this is ugly, try applying this to java, where the concept of "file" (since the classes can be in a zip file) an app (since there is no concept of an 'executable' - just entry points), or even a 'process space' is vague.
Replace 'file' with 'class' for java. That takes care of it, I think.
uh, nope. As java source files can compile into MANY .class files (inner classes).
That's ok, I think. The .class files are all related only by dynamic linking.
I don't think we need to define application. If we did, 'hunks of executable code in the same address space/process', or a collection thereof, might do.
but this would include everything that that particular jvm is running at the time, including the "libraries" like swing, and other java.* stuff.
It really is pretty ugly trying to apply *gpl to java.....
I believe that every interface provided by the Java spec and implemented by the JDK is a platform/os interface, and thus GPL and LGPL apps are specifically allowed to link to it by the GPL/LPGL os linkage exception.
- Dan