I guess I'm on. Disclaimer: I'm talking about what's available in Apple's core library - not the gnustep stuff since I don't use it - but the gnu people have a pretty similar if not identical clone.

1) Threading - ease of use, completeness of libraries, performance

Objective C threads are thin OO wrappers on top of pthreads. The interesting class is NSThread. The thread entry point is a message on an object. The call is

[NSThread detachNewThreadSelector:@selector(startThreadWithArgument:) toTarget: someObject withObject:argument];

There are useful helpers like NSLock, NSPort (for accessing mach kernel ports - io points between processes or threads). Its pretty easy to use.

There's a wacky sort of cooperative thing called an NSTimer. It can be used as a one shot deferred call or it can repeat. Its the same basic deal - you give it an object, message, argument (if any), time to fire and a repeat rate. Its pretty useful if you want to set up a little polling task to clean something up later.

In Squeak the thread model is entirely a green threads implementation. Squeak lets you split off an arbitrary chunk of code in a block using something like:

[ a block of code ] fork.

or you can forkAt: priority. This gives you back a Process object. There have been some experiments in things like named processes that can be suspended, cloned, restored from files... Interprocess communication is by way of semaphores and shared queues.

2) Networking primitives - as above

Objective C you have access to regular BSD sockets because - hey its C. Next/Apple has never supplied a really good (read - easy to use in a general case) wrapper. But there are plenty of free ones: [link|http://blackholemedia.com/code/|http://blackholemedia.com/code/] has a bunch of BSD licensed goodies.

Squeak has some sockets that are implemented as stream - but there's a move on to clean up the socket code - its not super good at error reporting. There is a completely different interface to communications created by [link|http://www.netjam.org/|Craig Latta] called [link|http://www.netjam.org/flow|flow]. Craig is a musician who has a project called netjam designed to allow real time music collaboration over the net. I haven't dug into it but it has a good reputation. You can get it from [link|http://www.netjam.org|http://www.netjam.org]

3) Overall performance

I have heard of very few instances where ObjectiveC itself caused a performance problem and the fix is pretty simple - switch to C right there in the code. It is possible to get a pointer to the C function implementing a message using the @impl(selectorName) keyword and call it as a C function within a tight loop - but this is *rarely* done. Regardless, you always have an easy out.

Squeak has been successfully embedded in real time systems. See [link|http://www.netjam.org/|Craig Latta]'s resume for one example. Its quite good I think. It doesn't feel slow. Your out in case of extreme performance requirements is to call out to a shared lib using the foreign function interface, or augment the VM with a plugin (which you can write in Smalltalk and generate C from if you want). Croquet offloaded nearly all their rendering to OpenGL (which offloads lots of its work to graphics co-processors). The results have been amazing.

Ralph Johnson had this to say recently on the VisualWorks list in response to the question "which is faster - Smalltalk or Java?"

Smalltalk and Java are about the same speed. When
Java first came out, it was at least 50 times slower
than the fastest implementation of Smalltalk, which is
VisualWorks. The fastest implementations of Java
are now faster than VisualWorks, probably twice as
fast on some benchmarks. But most implementation of
Java are still slower than VisualWorks. They are
probably faster than Squeak, though, which is a fair
bit slower than VisualWorks.

But all this is pointless. When Java or Smalltalk projects
are too slow, it is not because they were done in Java or
Smalltalk, it is because they were designed wrong.

Does Squeak require a visual environment to run a console or daemon application?

No, there are headless VMs, squeak script interpreters, etc...

I have a headless vm I compiled to run a swiki.

[link|http://www-sor.inria.fr/~piumarta/|Ian Piumarta] is the Unix VM god and I'm beta testing his 3.5 vm - which builds with support for both X11 and Cocoa on OS X. Its the grand unified unix vm. He has builds for other unixs. Has added a command line switch (-headless or something) and it won't even try to build a display device. He's building it so you can send it a signal and it'll pop the UI - useful for debugging a server gone south.