On Thu, 21 Aug 2003, John M McIntosh wrote:
> 
> Ah, but with 3.5.x which uses the unix logic for  
> aioPoll(realTimeToWait*1000);
> a SortedCollection(872->10 95->11 25->1 4->12 1->2 1->13 1->25 1->32)
> which is interesting...
> I'm wondering if a new linux/bsd folks can run the benchmark and report  
> what they see with the latest unix vm.

With the latest Unix VM:

emilia$ bld/squeak
 a SortedCollection(999->1 1->2)

emilia$ bld/squeak -notimer
 a SortedCollection(1000->1)

emilia$ bld/squeak -vm display=quartz
  a SortedCollection(999->1 1->2)

emilia$ bld/squeak -notimer -vm display=quartz
  a SortedCollection(1000->1)

felina$ bld/squeak -vm display=fbdev    # a creaky old 366 MHz laptop PC
  a SortedCollection(997->1 2->2 1->3)

felina$ bld/squeak -notimer -vm display=fbdev
  a SortedCollection(996->1 3->3 1->2)


> On Thursday, August 21, 2003, at 10:25  AM, Andreas Raab wrote:
> 
> > On XP using a 3.5.1 VM this yields:
> > 	a SortedCollection(990->1 10->2)
> 
> Mmm on the mac with 3.4.x which used  
> pthread_cond_timedwait_relative_np() under os-x we get
> 
> a SortedCollection(895->1 99->2 5->3 1->4)

I'm a little puzzled over how you detect i/o on your sockets while waiting
for your condition to be signaled (which presumably isn't going to happen
before the timeout, unless someone wiggles the mouse)...?

BTW:

> pthread_cond_timedwait_relative_np()
                                  **
"np" = non portable
     = not published
     = nefarious procedure
     = never permitted
    (= naughty programmer)

Ian

PS: You can avoid the doInitialization thing in your ioRelinqProc4us by
    defining your lock & cond as you declare them:

      pthread_mutex_t gSleepLock= PTHREAD_MUTEX_INITIALIZER;
      pthread_cond_t  gSleepLockCondition= PTHREAD_COND_INITIALIZER;