🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.next.programmer
4 messages
4 total messages Started by Richard Myers Thu, 30 Jul 1992 06:20
usleep and efficiency
#339
Author: Richard Myers
Date: Thu, 30 Jul 1992 06:20
16 lines
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
#347
Author: Geoffrey S Knauth
Date: Thu, 30 Jul 1992 10:14
11 lines
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
#392
Author: moose
Date: Fri, 31 Jul 1992 17:51
24 lines
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
#393
Author: Chris Lloyd
Date: Sat, 01 Aug 1992 18:17
18 lines
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