XOJO Linux Threads Useless

Targets Linux
1

Hello folks, new XOJO pro user here.

Some Background…

I have a UDP based application that has a roll-your-own congestion window, selective repeat, fast recovery, piggybacking, the works. To clarify, this application requires UDP to perform NAT traversal so the TCP socket was never an option, and the XOJO UDP socket performs quite well. I have been working on Xojo 3.1 under windows 7 and so far have not had any significant issues until now. Unfortunately, this application is to be distributed to students worldwide, particularly to a low-income (third-world, i.e. freeware) audience who will not be using windows as an operating system (if they have any at all) and thus will require to boot a DVD live CD of a Linux distro (TBD) to use this application on whatever serviceable hardware they can assemble to be able to boot the live CD (Their problem). To be sure, implementing NAT traversal and a customized ARQ/hints for high RTT VSAT and long haul 802.11x operation took less than a day, so my hats off to the simplicity of the Xojo language.

Now on to the problem:

Under windows 7, I have been using a thread to call the UDP socket’s poll method and continuously check the socket’s PacketsAvailable property to see if anything has arrived. When packets arrive, the thread executes a loop to read the socket until the PacketsAvailable property is zero. All the activity for the congestion control and ARQ are handled in the thread and the socket’s dataAvailable event is unused. Under windows 7 and 8 the compiled applications perform flawlessly, but when I compiled the application for the linux target, the applications use 100 percent of the CPU time even with no activity whatsoever. After pulling my hair out for a few days, I discovered that even idle threads consume 100% CPU under Linux (please see case 370) and this has been a known issue since 2007. To compound issues further, I have discovered this is also occurring under our single CPU Go Daddy virtual private server (running windows server 2008 r2, sp1) that is used to facilitate the students to connect to each other. I understand that Windows Server 2008 would in all probability not be supported, and a Linux replacement for the server could easily be used if it worked. In some desperation, I tried to use timers in place of threads which worked but delivered a pathetically slow 800kb over the wired lan. So I also tried aggregating multiple UDP sockets on different ports to make up for the tiny resolution that the timer provided to poll and read (and thus the limited throughput) This “works” for the low bandwidth text portion but will be useless to transfer the video based training material and is a bona fide hack-job to say the least. Each connection would have to use upwards of 10 concurrent UDP sockets to even approach the performance that is easily delivered under the functioning Windows 7 build, and adding even more uncertainty about how I will go about any realistic binary file transfer (critical to deliver the prerecorded video content) if I am forced to read the binary stream in a unthreaded loop, while operating the time sensitive congestion window in the same executable.

I have tried using the sleep, this does nothing to alleviate the usage under Linux; I have tried building simple ad-hoc thread tests using every distro and every computer I could lay my hands on. It’s Xojo’s threading under Linux, and I am not the only one to have discovered this issue, just look at the cases for “linux” and “threads”. To be clear, this application works correctly under both windows 7, 8 and even my macbook. Please take note that this will even cause thermal issues on Linux computers with prolonged usage, as all my test laptops fans operated in high very high RPM regimes during prolonged execution.

What I have tried:

  1. Raw thread class instanced and incrementing a simple integer counter, with a sleep(10) added in the loop, this works perfectly and idles at an amount that hardly registers. Under Linux, this consumes 100 percent on every system and distro I have.

  2. Timers: delivers about 2% of the performance and will do nothing to address simultaneous binary stream reading and congestion window operations.

  3. Running the thread without looping it, letting it run to completion and using a timer to instance a new thread when it is not running. (This method is useless as it still uses 30 percent of CPU time on each loop and is causing major interference with the ack clocking as it requires a very high sleep() interval to not consume the entire processor.

  4. Linux Mint, Ubuntu, CentOS, all 32 bit distros all exhibit the exact same issue. Honestly, I could use ANY distro that worked so I am NOT picky.

  5. Profanity and prayer, neither have helped, and I am slowly coming to terms with having to rewrite the entire application again, in another language.

My questions are this:

  1. Has anybody found any distro (any at all) that threads work correctly under?

  2. Does anybody know of a Real Studio IDE build that I could be using that threading functions correctly under Linux?

  3. Has anybody achieved “useful” binary file transfer performance with the sockets (UDP or TCP) under LINUX WITHOUT using threading of any kind?

  4. Does anybody have any possible workarounds they could suggest?

I’m greatly appreciative of any suggestions that you might have, thank you very much!

2

We use console project for server app. It uses TCP Sockets and can stream easily over 50 MB/s.
basically the app has a main loop which does run DoEvents.

do
if UploadCounter.Counter>0 then
DoEvents 0
else
DoEvents 1
end if
loop until ende

and as you see we have an optimization. If a transfer runs, we do DoEvents 0 to get 100% CPU but excellent speed.

PS: I think in general for network a thread will not help much.

3

Christian beat me to the punch, but I also use a Console app as a helper and call out to it for network I/O performance.

4

I, too, question the need for a thread here. Seems like it would only add overhead.

5

Seems a bug in Xojo Linux due to fact of working on Windows.
Fact aside, are you aware that Xojo does not have real threads (preemptive multitasking), are you?
Xojo have fibers (cooperative multitasking) but calls it threads, and when the cooperative task switcher does not “switch the task”, due to any cause, things go bad.
Maybe the Linux framework task scheduler/switcher was implemented differently from the Windows version, in such way it causes the CPU hog in your pooling fiber.
Can a timer ticking be enough for your pooling task?
Can you create a small proof of concept to show the case to the engineers (a sender and a receiver test case for example) about the different behaviors on Windows and Linux so they can find the problem and fix it?

6

There’s no doubt about it being a bug. The simple example of incrementing a number and sleeping should be enough to demonstrate the problem. Please do file a bug report if there isn’t a recent one already. Or make a comment on the old one so they know it’s still a problem. In either case, attach your simple example project.

7

[quote=157030:@Christian Schmitz]We use console project for server app. It uses TCP Sockets and can stream easily over 50 MB/s.
basically the app has a main loop which does run DoEvents.

do
if UploadCounter.Counter>0 then
DoEvents 0
else
DoEvents 1
end if
loop until ende

and as you see we have an optimization. If a transfer runs, we do DoEvents 0 to get 100% CPU but excellent speed.

PS: I think in general for network a thread will not help much.[/quote]

I just tried this example on a simple test construct, and it seems to be working as advertised on Linux, I will follow up with more detail after re-factoring the existing design. Thank you all very much for your help, it has been appreciated. It now looks as if I can move forward again. :slight_smile:

8

[quote=157054:@Rick Araujo]
Fact aside, are you aware that Xojo does not have real threads (preemptive multitasking), are you?

Sure, I have seen this mentioned before.

Can a timer ticking be enough for your pooling task?

Unfortunately no, even with a period of zero, the timer’s resolution is capping out the throughput at dsl speeds over wired Ethernet.

Can you create a small proof of concept to show the case to the engineers (a sender and a receiver test case for example) about the different behaviors on Windows and Linux so they can find the problem and fix it?

I certainly could if you think it would be of help, but I was able to reproduce the problem with a ad-hoc test project containing a single thread looping an increment of an integer, and nothing else. This behaved correctly under windows 7, with no noticeable CPU increase, while on Linux, it ran with the throttles to the stops, the instant the run method was called. Exactly as described in <https://xojo.com/issue/370>

I will add the example. It is encouraging to see that as Christian said he has an XOJO based design that “can stream easily over 50 MB/s” That’s a gigantic relief, regardless of the amount of redesign needed, I will be totally satisfied with my Xojo Linux executable that can achieve even 10% of that. This console based design seems to show promise.

Thanks again guys, very helpful. :slight_smile:

[/i][/quote]

9

32 bits apps of present Xojo cannot take advantage of multicore threading. One of the great advantages of using helpers is that they execute on a different core than the main app. So when a “thread” in fact steals resources from the main app, the helper gets the full power of its own processor core, without taking a tick out of the main app processing power. It is a win-win technique.

10

A helper is not a substitute for real preemptive threading and there is no advantage and many disadvantages using different executables to simulate this. I hope new framework gets real threading very soon (at least console Apps) among LLVM and 64 bit… A dream!

11

but I still wonder if Juyoun found a bug in thread handling.

12

Except for the advantage that helper apps are available right now.

13

Still are not substitute for real threading. Helpers (A process) has nothing in common with real Threading programming. That’s why I insist helpers are not a substitute. Is like comparing Apples and Oranges. Sorry :slight_smile:

14

The OP needs a solution now to manage communication without maxing the CPU. Not a lecture about the difference between preemptive threading and a helper app. Between ideal and available, the choice is all a matter of being pragmatic.

Incidentally, I did not mention anywhere preemptive threading, just made the remark that what 32 bit Xojo calls threads are in fact a distraction of CPU time from the app through time sharing.

That said, it will be nice when Xojo 64 bit is here. With some luck, it will support multiple cores, and even better luck, real threading. If all goes well, 64 bit at least is for this year, right after iOS which should be here next February (fingers crossed).

15

For years… sadly the only option. Always this way with support messages like “this is the current way” :frowning:
And having the greed side effect of 100% CPU consumption in Linux in similar cases like that pointed by Juyoun. And not having the great support of real threads that when you just kill that ONE process (close app or sending a kill signal to the process) and all it’s threads will gracefully die together as planned, and killing separated processes in some bad order (like main then helper, or helper then main?) can have unpredictable results. And in some systems helper processes appears as running programs in the “tasks bar” on that OS making the user confuse, the task bar dirt, and looking as a bad designed app. Etc, etc, etc. But as Michel said, crossing fingers for new frameworks being able to handle real threads ASAP. Web, data comm and heavy apps thank you all. :slight_smile:

16

The work being done for 64-bit has no impact on cooperative versus pre-emptive threading.

17

Hmmm. Seems that Xojo will still cooperative for some more time… :stuck_out_tongue:

18

In other words, the first 64 bit version will use LLVM with the 64 bit option, and no fundamental change otherwise ?

That should immediately mean a huge speed gain, if I judge from XojoScript performances, I remember execution times of about half within the 32 bit apps. Should be even faster for some operations in 64 bit. That will already be a fantastic improvement.

Now, what about the 64 bit app being able to take advantage of several cores ? Is it automatically the case because of 64 bit ? Is LLVM intelligent enough to transparently manage cores or does it fall on Xojo ?

I understand preemptive threading is a horse of a different color that a simple option switch in the compiler cannot automagically make happen. From what I remember of some IBM conferences a while ago, it is not trivial. One can just make a wish, right ?

19

It’s an old wish Michel. It touches so many places in the framework that they (until now at least) decided to postpone to a later time WHEN they would need to rewrite the frameworks and compiler! Like right now. :stuck_out_tongue:

20

Correct.

A huge speed gain on math-heavy code. Please don’t expect all code to magically get faster by significant margins.

It’s not automatic.