Skip to main content

CodeSOD: Pulling at the Start of a Thread

4 days 3 hours ago

For testing networking systems, load simulators are useful: send a bunch of realistic looking traffic and see what happens as you increase the amount of sent traffic. These sorts of simulators often rely on being heavily multithreaded, since one computer can, if pushed, generate a lot of network traffic.

Thus, when Jonas inherited a heavily multithreaded system for simulating load, that wasn't a surprise. The surprise was that the developer responsible for it didn't really understand threading in Java. Probably in other languages too, but in this case, Java was what they were using.

public void startTraffic() { Configuration.instance.inititiateStatistics(); Statistics.instance.addStatisticListener(gui); if (t != null) { if (t.isAlive()) { t.destroy(); } } t = new Thread(this); t.start(); }

Look, this is not a good way to manage threads in Java. I don't know if I'd call it a WTF, but it's very much a "baby's first threading" approach. There are better abstractions around threads that would avoid the need to manage thread instances directly. I certainly don't love situations where a Runnable also manages its own thread instance.

This is almost certainly a race condition, but I don't know if this function is called from multiple threads (but I suspect it might be).

But what's more interesting is where this code gets called. You see, starting a thread could trigger an exception, so you need to handle that:

public void run() { while (true) { try { loaderMain.startTraffic(); break; } catch (Exception e) { System.out.println("Exception in main loader thread!"); e.printStackTrace(); } } }

Inside of an infinite loop, we try to start traffic. If we succeed, we break out of the loop. If we fail, well, we try and try again and again and again and again and again and again…

Jonas writes:

Since I'm the only one that dares to wade through the opaque mess of code that somehow, against all odds, manages to work most of the time, I get to fix it whenever it presents strange behavior.

I suspect it's going to present much more strange behavior in the future.

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.
Remy Porter

Apple Must Halt Non-App Store Sales Commissions, Judge Says

4 days 4 hours ago
Apple violated a court order requiring it to open up the App Store to third-party payment options and must stop charging commissions on purchases outside its software marketplace, a federal judge said in a blistering ruling that referred the company to prosecutors for a possible criminal probe. From a report: U.S. District Judge Yvonne Gonzalez Rogers sided Wednesday with "Fortnite" maker Epic Games over its allegation that the iPhone maker failed to comply with an order she issued in 2021 after finding the company engaged in anticompetitive conduct in violation of California law. Gonzalez Rogers also referred the case to federal prosecutors to investigate whether Apple committed criminal contempt of court for flouting her 2021 ruling. The U.S. attorney's office in San Francisco declined to comment. The changes the company must now make could put a sizable dent in the double-digit billions of dollars in revenue the App Store generates each year. The judge's order [PDF]: Apple willfully chose not to comply with this Court's Injunction. It did so with the express intent to create new anticompetitive barriers which would, by design and in effect, maintain a valued revenue stream; a revenue stream previously found to be anticompetitive. That it thought this Court would tolerate such insubordination was a gross miscalculation. As always, the cover-up made it worse. For this Court, there is no second bite at the apple. It Is So Ordered.

Read more of this story at Slashdot.

msmash

Why Windows 7 Took Forever To Load If You Had a Solid Background

4 days 6 hours ago
An anonymous reader quotes a report from PCWorld: Windows 7 came onto the market in 2009 and put Microsoft back on the road to success after Windows Vista's annoying failures. But Windows 7 was not without its faults, as this curious story proves. Some users apparently encountered a vexing problem at the time: if they set a single-color image as the background, their Windows 7 PC always took 30 seconds to start the operating system and switch from the welcome screen to the desktop. In a recent blog post, Microsoft veteran Raymond Chen explains the exact reason for this. According to him, a simple programming error meant that users had to wait longer for the system to boot. After logging in, Windows 7 first set up the desktop piece by piece, i.e. the taskbar, the desktop window, icons for applications, and even the background image. The system waited patiently for all components to finish loading and received feedback from each individual component. Or, it switched from the welcome screen to the desktop after 30 seconds if it didn't receive any feedback. The problem here: The code for the message that the background image is ready was located within the background image bitmap code, which means that the message never appeared if you did not have a real background image bitmap. And a single color is not such a bitmap. The result: the logon system waited in vain for the message that the background has finished loading, so Windows 7 never started until the 30 second fallback activated and sent users to the desktop. The problem could also occur if users had activated the "Hide desktop icons" group policy. This was due to the fact that such policies were only added after the main code had been written and called by an If statement. However, Windows 7 was also unable to recognize this at first and therefore took longer to load.

Read more of this story at Slashdot.

BeauHD