fork() is a nasty libc function to implement on Win32. Fortunately Win32 CreateProcess() is rather close to fork() followed by exec().
It seems there are many different system calls for process spawning on Linux these days.
The quesion is: how do I make fork+exec portable and use CreateProcess() on Windows?
So on Unix it does something like this (cross chroot/chdir of course):
https://github.com/mindcat/pacman/blob/master/lib/libalpm/util.c#L529
And on Windows it does something like this:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx
Are there any existing wrappers?
Did you consider using some cross-platform libraries like glib (with spawning process facilities), Qt with QProcess, Poco, boost process, etc etc.... ?
Then you could (in principle) write source code which runs both on Windows and on Linux.
(you don't "port" fork+ exec to Windows, you only use higher level constructs provided by such libraries to create new processes).
Related
According to the INSTALL docs,
On some platforms, perl can be compiled with support for threads. To enable this, run
sh Configure -Dusethreads
The default is to compile without thread support.
With the thread implementation being pretty stable, how come it isn't a default build option? The build option seems to be set by at least Debian and Alpine Linux. Is there any good reason to build Perl without threads? What are the downsides to threaded perl?
Because threaded builds of Perl are 10% slower[1] than non-threaded, non-multiplicity[2] builds.
Your experience may vary.
Multiplicity is supporting multiple instances of the interpreter in one program. -DMULTIPLICITY is implied and required by -Dusethreads (since each thread has its own interpreter).
I have Python code that works on Windows, however when running on Linux it just hangs. I'm using JPype, so I suspect that there might be some issue with multiple shared processes trying to use the same pipe to access Java (the different processes are created but hang at the JPype line). Is there any way to enforce spawning in Pathos to copy the Windows implementation? (e.g. set_start_method, or get_context in the regular multiprocessing library?)
Thanks.
To answer my own question (and it's a bit nasty) but after digging through the code you can:
import multiprocess.context as ctx
ctx._force_start_method('spawn')
Which happily solves the issue I'm having with JPype hanging. The difference between Linux and Windows is that as Windows spawns a new process, a new JVM is started (jpype.startJVM()), whereas a forked process has to use the same one (so I'm guessing that there are multiple processes trying to use the same pipe to Java). set_start_method doesn't seem to have been implemented, as far as I can tell.
I was wondering if there was an equivalent version either in a library or as a syscall, of the windows APIs which allow a process to interact with other process' space, which would mean modifying the flow of that second process.
This is to inject a .so in a running process without killing it.
Thanks!
maybe take a look here: CreateRemoteThread in Linux
I don't know of a simpler way than described there. On Windows you have this
fancy API like VirtualProtectEx. On Linux you'd be writing a .so which e.g. executes pthread_create
in a __attribute__((constructor)) function. Then you'd load that .so via the LD_PRELOAD mechanism.
The next best thing to CreateRemoteThread would be manipulating the main thread
of the process with the ptrace API. But this would involve
Holding a thread
Saving its context
Setting arguments for pthread_create
Set IP to pthread_create and execute
Restore the old context.
I think manipulating the memory access rights would also involve calling mprotect from a process context. As already mentioned above, the simplest way
to do that would not be using ptrace but using a precompiled shared object.
On Linux, there is a standard mechanism of injecting your code to a program. You basically define an encironment variable LD_PRELOAD that specifies a .so library that is loaded before all other .so files. Functions in that .so will replace standard versions of the functions. There is no need to modify the assembly code of fuctions manually to insert hooks to your own code like on windows.
Here is a nice tutorial: https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/
I am porting one Linux Application to Windows. I observed many changes need to be done in multithreading part.
what will be the equivalent structure for "pthread_t" (which is in Linux), in windows?
what will be the equivalent for structure for "pthread_attr_t" (which is in Linux), in windows?
Can you please guide me some tips while porting.
Thanks...
The equivalent to pthread_t would be (as is so often the case) a HANDLE on Windows - which is what CreateThread returns.
There is no direct equivalent of pthread_attr_t. Instead, the attributes of a flag such as the stack size, whether the thread is initially suspended and other things are passed to CreateThread via arguments.
In the cases I saw so far, writing a small wrapper around pthreads so that you can have an alternative implementation for Windows was surprisingly simple. The most irritating thing for me was that on Windows, a Mutex is not the same thing as on Linux: on Windows, it's a handle which can be accessed from multiple processes. The thing which the pthread library calls mutex is called "critical section" on Windows.
That being said, if you find yourself finding more than just a few dozen lines of wrapper code you might want have a look at the c++11 thread library or at the thread support in Boost to avoid reinventing the wheel (and possibly wrongly so).
Here is your tip - "pthread is POSIX".
Mingw has pthreads,
Cygwin have pthreads and so on.
My advice is to stick with mingw and try not to do any changes.
I'm getting confused on the idea of "pthread" and "thread". I know pthread is short form for POSIX thread, which is a type of standardized thread used in UNIX. But people often use "thread" to refer a thread. Are pthread and thread equivalent? Or pthread is only the name for threads used in UNIX?
Thanks in advance.
Threads are a generic concept. Wikipedia defines it as:
In computer science, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by an operating system scheduler. A thread is a light-weight process.
Pthreads or POSIX threads are one implementation of that concept used with C program on Unix. Most modern languages have their own implementation of threads. From that web page:
Pthreads are defined as a set of C language programming types and procedure calls, implemented with a pthread.h header/include file and a thread library - though this library may be part of another library, such as libc, in some implementations.
To add to Gray,
Pthread is POSIX complaint which means you can use it across most of the UNIX operating systems.
No need to rewrite them for each of Unix (Linxux,FreeBSD, etc) and the behavior would be same across all of them .
Pthreads refers to the POSIX standard (IEEE 1003.1c) defining an API for thread creation and synchronization. This is a specification for thread behavior, not an implementation. Operating-system designers may implement the specification in any way they wish. Numerous systems implement the Pthreads specification; most are UNIX-type systems, including Linux, Mac OS X, and Solaris. Although Windows doesn’t support Pthreads natively, some third- party implementations for Windows are available.
Three main thread libraries are in use today: POSIX Pthreads, Windows, and Java. Pthreads, the threads extension of the POSIX standard, may be provided as either a user-level or a kernel-level library. The Windows thread library is a kernel-level library available on Windows systems. The Java thread API allows threads to be created and managed directly in Java programs. However, because in most instances the JVM is running on top of a host operating system, the Java thread API is generally implemented using a thread library available on the host system. This means that on Windows systems, Java threads are typically implemented using the Windows API; UNIX and Linux systems often use Pthreads