equal
deleted
inserted
replaced
382 } |
382 } |
383 if (ret != KErrNone) |
383 if (ret != KErrNone) |
384 { |
384 { |
385 sockNum--; |
385 sockNum--; |
386 } |
386 } |
387 Logger().WriteFormat(_L("Created %d sockets, expected at least %d sockets"), sockNum, sockCount1); |
387 Logger().WriteFormat(_L("Created %d sockets"), sockNum); |
388 TESTL(sockNum >= sockCount1); |
388 |
389 |
389 // Not sure what use it is to test whether we can open at least as many sockets as previously. |
390 Logger().WriteFormat(_L("Freeing sockets in creation order")); |
390 // We can't assume that once we've freed all the sockets first time around that the ESock heap will |
391 for (i=0; i<sockNum; i++) |
391 // go back exactly to where it was before - this makes assumptions about the ESock algorithms. Why |
392 { |
392 // wouldn't ESock legitimately cache objects, for example? |
393 socks[i].Close(); |
393 //TESTL(sockNum >= sockCount1); |
394 } |
394 |
395 |
395 // |
|
396 // NOTE: |
|
397 // We do *not* free up the sockets but just close the session. This is to exercise the subsession |
|
398 // cleanup behaviour in ESock with a large number of sockets. We test that this cleanup operation |
|
399 // does not overflow the transport queue, as each subsession cleanup results in a message being sent. |
|
400 // |
|
401 |
396 #endif // (_DEBUG) } |
402 #endif // (_DEBUG) } |
397 |
403 |
398 CleanupStack::PopAndDestroy(socks); |
404 CleanupStack::PopAndDestroy(socks); |
399 |
405 |
400 CleanupStack::Pop(&ss); |
406 CleanupStack::Pop(&ss); |