Thread View: comp.sys.next.programmer
4 messages
4 total messages
Started by Richard Myers
Thu, 30 Jul 1992 06:20
usleep and efficiency
Author: Richard Myers
Date: Thu, 30 Jul 1992 06:20
Date: Thu, 30 Jul 1992 06:20
16 lines
1059 bytes
1059 bytes
2 questions 1. Why does a simple usleep(100000); *HANG* my app? Background: The program does a DPSTimedEntry. Do these conflict? also, it only hangs when I have the sound turned on for the app. also, it doesn't COMPLETELY hang. If I'm running from a shell, I can send a ^C and it'll continue. (Yes, I'm pretty sure it's the usleep from gdb. No, it's not consistent (takes variable # of usleeps to hang)) 2. Is there an EASY way of finding out which way to code a line faster. eg. should I say if 'fabs(x) > 2' or '(x > 2.0) || (x < -2.0)'? I'd like a faster way to test this than doing a full profile run! [BTW, the second way is faster]. Thanks, Kurt
Re: usleep and efficiency
Author: Geoffrey S Knauth
Date: Thu, 30 Jul 1992 10:14
Date: Thu, 30 Jul 1992 10:14
11 lines
1018 bytes
1018 bytes
In article <2A778A16.26787@noiro.acs.uci.edu> rmyers@dec5200.acs.uci.edu (Richard Myers) writes: >2. Is there an EASY way of finding out which way to code a line faster. >eg. should I say if 'fabs(x) > 2' or '(x > 2.0) || (x < -2.0)'? I'd like >a faster way to test this than doing a full profile run! >[BTW, the second way is faster]. The easiest way is to remember that fabs() is a function, not a macro, and hence has more overhead than the second, more explicit expression. -- Geoffrey S. Knauth, Marble Associates, Inc. Member BCS-NeXT, LPF gsk@marble.com, (617) 891-5555 work, (617) 547-5247 home Standard Disclaimers
Re: usleep and efficiency
Author: moose
Date: Fri, 31 Jul 1992 17:51
Date: Fri, 31 Jul 1992 17:51
24 lines
1436 bytes
1436 bytes
In article <2A778A16.26787@noiro.acs.uci.edu> rmyers@dec5200.acs.uci.edu (Richard Myers) writes: > 2 questions > 1. Why does a simple usleep(100000); *HANG* my app? > Background: The program does a DPSTimedEntry. Do these conflict? > also, it only hangs when I have the sound turned on for the app. > also, it doesn't COMPLETELY hang. If I'm running from a shell, > I can send a ^C and it'll continue. (Yes, I'm pretty sure it's > the usleep from gdb. No, it's not consistent (takes variable # > of usleeps to hang)) > Because DPSTimedEntry uses threads, and threads and signals get along about as well as any two middle eastern nations, you should not do this. However, there is a wonderful example which uses mach ports timing out to implement a non-signal dependant sleep. I forget where, but it's in NeXTDevelopers/Examples. -- Michael Rutman | moose@svcdudes.com Cubist | makes me a NeXT programmer Software Ventures | maker of MicroPhone II #include <std.disclaimer>
Re: usleep and efficiency
Author: Chris Lloyd
Date: Sat, 01 Aug 1992 18:17
Date: Sat, 01 Aug 1992 18:17
18 lines
1232 bytes
1232 bytes
In article <1992Jul31.175146.23460@svcdudes.com> moose@svcdudes.com writes: > However, there >is a wonderful example which uses mach ports timing out to implement a >non-signal dependant sleep. I forget where, but it's in >NeXTDevelopers/Examples. Timeout on mach message send/recv (as used by SortingInAction) seemed to be the way to do this, but I've started using: thread_switch(THREAD_NULL,SWITCH_OPTION_WAIT,timeout); Where timeout is in milliseconds. No ugly port allocate/deallocate and it does the trick. la la la, -- :: Christopher Lloyd :: a74k110@titan.ucc.umass.edu :: Yrrid, Inc. :: :: AAAAAAAAAAAAAAAAAAAIIIIIIIIIIIIIIIIIIIIIIIGGGGGGGGHHHHH!!!!!!!! ::
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads