Hi, I'm using Sun's WTK2.2 to develop mobile apps. I use GCF for networking. Now, if we use a UI thread to open a connection (calling Connector.open(...)), WTK gives a warning: "to avoid potential deadlocks, blocking operations (such as networking) should be called from threads other than UI" Now, question arise: 1) Is this "deadlocking", that WTK talks about, real deadlocking (nightmare) or just user interface blocking (inconvenient, but not a nightmare)? Or is there some easy deadlock trap to be fallen in when calling blocking operations from the UI thread? 2) Just by the way, I haven't been able to find a version of Connector.open that DOESN'T block - does such even exist in MIDP, or is there really no way to open a client->server connection without that wee bit of blocking? -- Mikko

There isn't a way. Or rather, the way to get "non-blocking" behaviour is to do it in a separate thread, just like it suggests to you. That way, only that thread blocks (waiting for the connection to actually open).

It's the same as any other blocking I/O, e.g. like using "cin.get()" to pause a C++ program. The thread making the request can't do anything until the other end actually responds - which could be a long time in "processor years". And if somehow a "circular wait" gets set up (i.e. someone other thread blocks waiting for your thread to finish, but your thread is somehow also dependent on that other one), you get deadlock - in the real sense.