+3  A: 

As Groovy is based on the Java virtual machine, you get support for true threads.

Reginaldo
+1  A: 

Thread syntax may be static, but implementation across operating systems and virtual machines may change

Your scripting language may use true threading on one OS and fake-threads on another.

If you have performance requirements, it might be worth looking to ensure that the scripted threads fall through to the most beneficial layer in the OS. Userspace threads will be faster, but for largely blocking thread activity kernel threads will be better.

Aiden Bell
He said he's not interested in "green threads". So no, userspace threads don't count.
Crescent Fresh
Fair point, but most modern operating systems support kernelspace threads, in contrast none of the modern scripting languages seem to do so.True threads was meant in contrast to processes, in order to exclude answers that point me to pythons multiprocessing module or the like.
Ludwig Weinzierl
@Ludwig ... This is what I mean. There is a difference between syntax support and real support. Different Python vms may handle the semantics of the same threading syntax in a different way. Same goes for scripting languages on other operating systems.
Aiden Bell
@cresentfresh - Acknowledged. Missed that :)
Aiden Bell
I don't actually care too much about the colour of my threads;-)Seriously, as I understand it green threads can't run on multiple cores, so they don't count.
Ludwig Weinzierl
+4  A: 

You can freely multi-thread with the Python language in implementations such as Jython (on the JVM, as @Reginaldo mention Groovy is) and IronPython (on .NET). For the classical CPython implementation of the Python language, as @Dan's comment mentions, multiprocessing (rather than threading) is the way to freely use as many cores as you have available

Alex Martelli
+3  A: 

You seem use a definition of "scripting language" that may raise a few eyebrows, and I don't know what that implies about your other requirements.

Anyway, have you considered TCL? It will do what you want, I believe.

Since you are including fairly general purpose languages in your list, I don't know how heavy an implementation is acceptable to you. I'd be surprised if one of the zillion scheme implementations doesn't to native threads, but off the top of my head, I can only remember the MzScheme used to but I seem to remember support was dropped. Certainly some of the common lisps do this well. If ECL does, it might work for you (embeddable). I don't use it though so I'm not sure what the state of it's threading support is, and this may of course depend on platform.

[Update] Also, iirc GHC Haskell doesn't do quite what you are asking, but may do effectively what you want since, again, iirc, it will spin of a native thread per core or so and then run it's threads across those....

simon
I cleaned up the list with 'scripting' languages, thanks.TCL is a good hint though, neither GIL nor green threads as it seems.
Ludwig Weinzierl
TCL has it's own approach, but you can certainly get it to use all of your cores, if that's the primary issue. At least on the platforms I've done that on (which wasn't recent). I suspect it may not be in the default build either, but it can be turned on and rebuild easily enough.
simon
+1 for tcl. Thread implementation is as intuitive as well
Byron Whitlock
Tcl most certainly does spin up native threads; that's pretty much the only reason you'd want to use them in that language anyway (as it has strong async I/O support). They're also robust and have very few shared locks so you get good performance; they've had a lot of production pounding in things like heavy duty webservers...
Donal Fellows
+1  A: 

CSScript in combination with Parallel Extensions shouldn't be a bad option. You write your code in pure C# and then run it as a script.

Igor Brejc
+1  A: 

F# on .NET 4 has excellent support for parallel programming and extremely good performance as well as support for .fsx files that are specifically designed for scripting. I do all my scripting using F#.

Jon Harrop