Navigation:  Programming Cookbook > Sockets Connectivity > The Socket Connection Interface >

Blocking the User Interface Main Process

Previous pageReturn to chapter overviewNext page

Note: if you find the following explanation difficult to understand, don't worry; it is not necessary to do so in order to use Sockets effectively.

Since the asynchronous function calls that Sockets Connection makes use of, use Windows messages as their callback mechanism, it is important that the main message processing loop in Dolphin always continues to run. In order to guarantee this, if you execute a blocking Socket call in the user interface process (say by evaluating it in a workspace), then another temporary UI process will be started to take over as the first one is blocked. This allows the callback notification messages generated by the WSA calls to continue to be processed. When the operation completes, the blocking semaphore may then be signalled and the original process will be released. Eventually, when the original process runs to completion, it will be terminated and you'll be left with the same number of basic processes running in the system, it's just that the UI process will now be a different one.

We only mention this here, since it can create some slightly strange effects when evaluating blocking calls from within a workspace. You'll find, if you issue such a call, that it actually appears not to block since the user interface remains alive. This allows you to evaluate more expressions and perform other UI activities before the original call returns.