Resources | Resources |



Use of IShell_PostEvent() vs. IShell_Resume() for socket code

Note: ISockPort replaces ISocket and is recommended for better performance.

The ISocket interface provides the ISockPort_Readable() and ISockPort_Writeable() methods to allow data to be read and written in multiple chunks in the cooperative multitasking environment, which can help avoid one task locking up processing resources and resulting in unresponsiveness of the handset. Both ISockPort_Readable() and ISockPort_Writeable() register a callback function with the system to allow the registering applet to be notified (by invoking the callback) when more data is ready to be processed.

There may be additional tasks to be done when the callback is invoked besides processing data (such as updating the progress bar or storing data in the file system). If these additional tasks can be completed without breaking the cooperative multitasking principle, meaning they do not block others for too long, they should be done directly inside the callback function for the optimal performance. However, if the additional tasks may take too much time to complete in a blocking fashion, an application can call IShell_Resume() to register the callback from within the same callback used for ISockPort_Readable() or ISockPort_Writeable(), then yield the CPU and receive a notification at a later time.

An alternative to calling IShell_Resume() to avoid blocking operations is to use IShell_PostEvent(). However, there is a performance penalty to pay with IShell_PostEvent(). The typical use of IShell_PostEvent() is to post an event to a specified applet, which is a relatively expensive call compared to IShell_Resume(). Unless the additional tasks are intended for other applets to complete, all that is needed is an asynchronous callback method that can be achieved using IShell_Resume(), which is lightweight compared to IShell_PostEvent().

The aforementioned considerations are particularly important to the implementation of MMS and browser engines, which heavily rely on networking socket interfaces. The recommendation is that the engine be designed as an in-process class rather than a separate applet class, which allows it to be executed in the same context as its UI application; IShell_Resume() rather than IShell_PostEvent() can be used when time consuming tasks need to be performed in the ISockPort callback.

For more information on in-process classes, see the Brew MP Programming Model on the