It seems you are alone to test LimeWire on OS/2. It seems to be an issue with the virtual memory management (with committed memory) on OS/2, and difficulties to handle multiple threads efficiently on this platform, and to support CPU throttling:

I note that you share a lot of files, but you have erased your THEX data cache. This is still a new feature in LimeWire, ant i will take time until all your files are indexed.

What seems to happen is that this occurs the first time a user starts downloading from you with THEX control. THEX tree data is not computed immediaely when you add files in the library. Instead it is computed in parallel with uploads.

I made special efforts to maximize the throughput and efficiency of the THEX hasher (which is running on is own thread on your host), so that it won't take lot of time to compute. However, throttling of this hasher by concurrent threads seems to be ineffective on OS/2. As there's nobody at LimeWire or in our open-sourcers that has worked to see what's happening on your platform, there's littel we can do to help you.

One suggestion:
Exit limewire, save your limewire.props file and the thex and urn cache files as well as the file stats cache.
Then restart with much lower number of shared files (for example reset the configuration to share the default share directory).
Restart and share only a few popular (but not too large) files, and see what is happening. You'll see a CPU spike when the first file will be uploaded, when this file gets THEX-hashed.
It should return to normal just after.
If you see that, then it just happens because your thex cache file was emptied.
You may then restore your saved settings. No immediate solution for you on OS/2 until all your popular files get THEX-hashed on demand. I recommand you check your system settings related to virtual memory management (if you don't have a permanent and unfragmented swap space, you could experiment long delays o perform efficient multithreading).


On Windows, my UltraPeer (using an Athlon XP 1800+) handles more than 450 concurrent threads with 5 to 10% of CPU usage...