So I thought it would be useful for empegVNC to be multithreaded (for purposes not yet revealed ). It was easy enough to implement initially using pThreads. However, when I ran it on the empeg, I noticed that it actually created multiple processes. This is remarkably annoying, as I was using threads solely to avoid creating the overhead of multiple processes (and, maybe, to control the scheduling of the process). Am I doing something dramatically wrong (I'm using only pthread_create() and pthread_detach() from the pThreads API at this point) or is this the expected behavior of pThreads on a Linux (or arm-Linux?) platform? If it's expected, is there a more lightweight thread API I should be using?

I'm not 100% knowledgeable about pthreads-on-linux, but the Linux kernel does NOT distinguish between threads and processes. They are all treated the same internally, except when created. So, one can create lightweight threads (eg. kftpd, khttpd), but they will appear to be ordinary processes when queried.

You might be able to distinguish between them by looking that the process flags, possibly available somewhere under /proc/$pid

-ml

So it's possible that they're still LWPs, but they're each assigned full-on PIDs by the kernel anyway for internal reasons? I'll take a look at the /proc structure to see if it provides any info. Thanks.

pthreads uses the clone system call to work. The extra processes are actually the same as the main program. It just represents each thread.

- Trevor

Well, if they share the same address space (without explicitly attaching to shared memory segments) then they would appear to be 'lightweight'...

I don't think threads will speed up your app or lower it's resource hunger. Forked processes also share the same readonly memory-regions and are created as fast as threads. When running displayserver in threaded mode, I saw an increase in memory usage, due to the extra thread libs. Another disadvantage is the fact that your complete application will die if an unexpected error occurs in one of your threads

It looks like you may be right. Linux's thread implementation seems to leave something to be desired. I'll do a little more research before reverting to separate processes, but, damn, I was looking to put that pthreads book I bought years ago finally to some good use.

The threads do share the same memory space (we use pthreads in the player) and this helps quite a bit on the strongarm - no D-cache flush (an expensive operation on the strongarm) is required when context switching to another process/thread with the same memory map.

Hugo

I was under the assumption that every thread would use it's own stack, which is default 8k, which is the same for normal processes. If I look at the difference in size however, I see a major difference :
output from top :

   PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND

  26 root       0   0    96   96    64 S       0  0.0  0.8   0:00 ds2

  321 root       0   0   312  312   236 S       0  0.0  2.8   0:00 displayserve

threaded = 312-236 = 76 k
mprocess = 96 - 64 = 32 k

running the free command before and after starting threaded ds shows a memory increase of 92 k, which would indicate two stacks (8k+8k) are used, as there are two threads running after startup.
Context-switches are probably a lot more efficient using threads, but aren't an issue when another realtime app is running, which will always cause efficient context-switching hard to guarantee.

I'll try to experiment some more; I ran these tests with a very old version of displayserver and I will try to put some load on the threads/processes.
I was able to open 10+ applets concurrently with the player app in mprocess mode, while in threaded mode it would shut down the complete app when trying it. Probably also caused by the real-time nature of the player app. It probably also happens in the mprocess-version, but isn't noticed as only the last process is terminated...