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).
Related
I need to prevent some programs from running in parallel (last time I checked there was RUST_THREADS=1 option but can't find any docs for it) because they screw up the display.
I'm running a program from cargo, but I'd prefer to do it for executive form of program (i.e. instead of cargo run I could use ./myprogram).
By default Rust uses native threading, and you can't just disable it. It just doesn't make sense and will almost certainly break multithreaded program completely - it is because native thread scheduling is done by OS, so hypothetical "disabling" of native threading will leave all programs with their main thread only.
It is possible to disable green threading, but Rust does not use it by default for a long time already. This is possible because green threads rely on user-land scheduler, usually implemented in a language runtime, and it usually can be configured to use single OS thread. This is the default mode of operation of Go, for example. Rust switched to native threading as it is closer to underlying OS, more effective and much easier to implement and support, so RUST_THREADS does not work anymore (even if it ever worked).
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).
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 wonder what the different is between the options 'THREADS' and 'PTHREAD' when I compile perl 5.16 (and other version) from port source in freebsd?
Is the PTHREAD the posix-threading? (because -pthread) And if so, is it prefered to 'THREADS'? (because it seems to be preselected) even on freebsd? And what is 'THREADS' (Kernel threads?) on the other hand? What are the pros and cons?
Could I use both in one installation? Is it sensefull?
There is not to much to find around in combination with perl, as far as I can see.
thanks a lot
jimmy
Using threads is as others have described it of course.
The link with pthread means that your perl is built with the -pthread flag. This has a subtle but important effect. It means that when perl starts up, the libc data that maintains state for threads is initialized. This means that if your perl calls dlopen() on a library which is threaded, it will work properly, instead of hanging.
PS. I'm actually the person who wrote and committed the PTHREAD option to the port. I actually discovered some perl modules which dlopen()'d some threaded libs and caused perl to hang. Took me a while to figure out why. Trust me, you want the PTHREAD option on. I'm actually thinking of removing the option to turn it off. For more info, see FreeBSD PR 163512 and 163878. We probably should push this option upstream so that perl uses this by default on FreeBSD. Anything that may call dlopen() should really be built with -pthread.
Now here's something interesting. When I have more than one thread in Tcl invoking package require Expect, I get a seg fault.
e.g.
package require Threads
package require Expect
set t [thread::create]
thread::send {package require Expect}
puts "blarg! Damned thing crashes before I get here"
This is not a good time. Any thoughts?
Expect and Threads don't go together too well. Its the complexity you get from fork() + threads that can bite a lot there and lead to deadlocks and all kinds of uglyness. Usually not a good idea to combine the two.
If you really need Expect and the added concurrency a multi process approach with on multi threaded driver program and one single threaded expect process might work better. If you used tcllibs comm package the api's for sending commands are not that much different either (you mostly miss the tsv and tpool stuff if you used comm).
But it shouldn't segfault for sure. Which Expect/Threads/Tcl core combination did you use (e.g. ActiveStates ActiveTcl bundle or some self compiled stuff on an unusual platform?)
It's all from the latest debian packages, Ubuntu 9.0.4, 64 bit.
One alternative is to organize the code such that one thread is dedicated to handling all expect calls...which isn't the most elegant, generic solution but it might have to do.
The C code of the expect library (loaded with package require Expect) is not thread-safe (it probably uses global variables or else). I tried a lot to work around this limitation because I wanted to have a load balancing algorithm based on the Thread library which would pilot some expect code launching builds on a pool of slave machines. Unless you are very good at C and want to enhance expect, I would rather suggest to launch expect interpreters (in their own OS process) each time you need to use it from your Thread-enabled program. But of course I don't know your problem to solve, and this would only work if the "expect works" are unrelated.. Good luck anyway..