Socket communication freezes unless the user initiates a UI event (in built apps)

My app communicates with iOS app via sockets. It works great in Carbon, but in Cocoa my users have complained that transfer of data stops unless they move the mouse, press a key, etc. IMPORTANT – this only happens in built apps. When running in the IDE this bad behavior cannot be reproduced.

I’ve found the exact same behavior happens with Xojo example projects:


Run the built apps. Click Listen in the ServerSocketExample. Now click Connect in the ClientSocketExample. The first time the server receives the event. The second time and thereafter it does not. But if you move the mouse over the ServerSocket window, the event is suddenly received.

When running in the IDE the events are received without user intervention, as expected.


This one has been there for a long time. Create a Timer that fires every 500ms or so and Poll the socket. Tune the period to get the performance you need.


Is this only for Cocoa? i.e. One wouldn’t have to do this for their Windows or Linux variants of the product?

@ Brad Hutchings. I do see it in Cocoa RS2012R2.1. But I never saw it in Carbon…

I saw it in Carbon a few years ago. Basically, it’s an event loop issue. The main thread needs to allocate some time to poll sockets. I know they’ve recently reworked the main event loop in Cocoa. Perhaps that was overlooked.

I’ve put the timer in for years on windows. It’s the only way to get the app to be responsive. The dataavailable event seems to fire quite well with big dollops of data, but with the last few bytes you’re waiting on it just doesn’t seem to be reliable (or very slow at best). I have subclassed the TCPSocket and added a poll timer that has it’s mode set to multiple in the connected event and set to stopped in the Error Event (error 102).

One absolutely brilliant thing with Xojo is that you can override the default templates (Desktop, Web etc.) by saving a project to the templates folder appropriately named with these toolbox items already subclassed and waiting for use.

You mention ServerSockets. Are you seeing this with normal sockets too?

We’re seeing this with TCPsocket.

I’ve just tripped over this problem too. I’ll give the timer a try. Thanks

Listening or connecting?

Listening. The communication starts, then no more data is received unless you move the mouse or press a key. I’ve instituted the timer and am polling the socket every 75 ms, and it’s working well now.

Just tried using a timer to poll the TCPSocket. It works just fine. Thanks.

I have two sockets operating at the same time and I was interested to observe that polling only one of them seems to resolve the “freeze” problem for both sockets.