Subject: usleep in menus.c

From: Brad Giaccio <[email-masked]>
Date: Wed, 3 Mar 1999 09:44:06 -0500

I've noticed this maybe a total of three times.  There is a usleep in menus.c, it looks like it is for the popup stuff, it is supposed to sleep for 10 ms but I ocasionally get a sigint during the usleep and then I fvwm hangs showing me the arrow cursor for menu selection, anyone else see this or am I just going crazy.

Brad
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Wed, 03 Mar 1999 10:51:34 -0500

Brad Giaccio <[email-masked]> writes:
> I've noticed this maybe a total of three times.  There is a usleep in menus.c
> , it looks like it is for the popup stuff, it is supposed to sleep for 10 ms 
> but I ocasionally get a sigint during the usleep and then I fvwm hangs showin
> g me the arrow cursor for menu selection, anyone else see this or am I just g
> oing crazy.

I haven't noticed any sigints, but I have noticed that there is no
prototype for the function.  Since its argument is a long,
if you are on a 64bit machine...

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 3 Mar 1999 14:03:36 -0500

> if you are on a 64bit machine...

Yes I am on a 64 bit machine but I do have a prototype for usleep an it takes an unsigned int.

Brad

---

From: Dan Espen <[email-masked]>
Date: Wed, 03 Mar 1999 14:32:46 -0500

> Yes I am on a 64 bit machine but I do have a prototype for usleep an it takes

I'm guessing we are talking about 2 different things.

Since usleep didn't seem to be 100% portable, there is a fvwm version
of usleep in libs/usleep.c.  It's first and only parameter is a long.

If you're OS calls usleep with an int, and its a 64 bit OS, this
tells me you are going to have a problem with usleep.

We just had some header file reorganization, so I'm not sure yet where
the right place to fix this is, but
you could try adding:

int usleep(unsigned long);

to the front of menus.c.

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 3 Mar 1999 15:49:25 -0500

> int usleep(unsigned long);

You are right I did miss the usleep in libs but mine doesn't get built into the library.  I tried running gcc on menus.c with the -E switch and I get 
typedef unsigned int    uint_t;
.
.
.
typedef uint_t      useconds_t;
.
.
.
extern int usleep(useconds_t);

now my solaris man page for usleep says that setitimer is the prefered
function over usleep, do you think it would be better to just replace
the calls to usleep with this or should I try forcing the arg as a long
first, although I'm not sure how that helps

Brad

---

From: [email-masked] (Paul D. Smith)
Date: 03 Mar 1999 16:32:25 -0500

%% Brad Giaccio <[email-masked]> writes:

  bg> now my solaris man page for usleep says that setitimer is the prefered
  bg> function over usleep, do you think it would be better to just replace
  bg> the calls to usleep with this or should I try forcing the arg as a long
  bg> first, although I'm not sure how that helps

You could try it and see if it helps, but we can't just replace it since
it's not a very portable function; we'd need some configure support for
it first.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Wed, 03 Mar 1999 17:14:57 -0500

> it's not a very portable function; we'd need some configure support for

Hmm.  I really am confused.

Now I look at my build area, I see that I don't build usleep either.
Apparently config figures out that I already have a usleep and
doesn't build it if it doesn't need it.

Based on your other mail, your compiler is seeing the vendor prototype
for usleep, so it should be converting the argument to usleep to
whatever the vendor usleep needs.

Wait, thats not  right either.  When I compile  menus.c with "-Wall" I
get this:

gcc -DHAVE_CONFIG_H -I. -I../../version-2_3_0/fvwm -I.. -I../../version-2_3_0/libs -I/opt/public/include -I/usr/openwin/include    -Wall -c ../../version-2_3_0/fvwm/menus.c
../../version-2_3_0/fvwm/menus.c: In function `MenuInteraction':
../../version-2_3_0/fvwm/menus.c:641: warning: implicit declaration of function `usleep'

So its not seeing a prototype, at least in Solaris 2.5.1.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

---

From: Steve Robbins <[email-masked]>
Date: Wed, 3 Mar 1999 20:33:15 -0500 (EST)

> int usleep(unsigned long);

I guess you're only suggesting this for testing purposes. 

That's fine, but please don't check in things like that! 

We should not be prototyping _any_ syscalls that live in the system
libraries.  There's just no way you're going to get them right for all
machines.

On the other hand, we *should* be prototyping the distributed usleep() for
systems that build it.  I have a feeling we're not doing this.

--
Steve Robbins                              <[email-masked]>

Too cool to live -- too smart to die.

---

From: [email-masked] (Paul D. Smith)
Date: 04 Mar 1999 01:12:14 -0500

%% Dan Espen <[email-masked]> writes:

  de> Now I look at my build area, I see that I don't build usleep either.
  de> Apparently config figures out that I already have a usleep and
  de> doesn't build it if it doesn't need it.

Yes.  That's why it's best to have it in a separate file, in lib.
That's how we generally handle potentially "missing" functions in
autoconf'd packages: there's special support macros for adding xxx.c
files to the build if you're missing function xxx.

  de> Wait, thats not  right either.  When I compile  menus.c with "-Wall" I
  de> get this:

  de> gcc -DHAVE_CONFIG_H -I. -I../../version-2_3_0/fvwm -I.. -I../../version-2_3_0/libs -I/opt/public/include -I/usr/openwin/include    -Wall -c ../../version-2_3_0/fvwm/menus.c
  de> ../../version-2_3_0/fvwm/menus.c: In function `MenuInteraction':
  de> ../../version-2_3_0/fvwm/menus.c:641: warning: implicit declaration of function `usleep'

  de> So its not seeing a prototype, at least in Solaris 2.5.1.

Bleah, looks like Solaris 2.5.1 is missing a prototype for usleep(),
even though the man page says you should #include <unistd.h>

I did a grep through /usr/include/*.h and /usr/include/sys/*.h on my
Solaris 2.5.1 system and couldn't find any prototype for usleep
anywhere... :(

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 4 Mar 1999 07:46:40 -0500

> Solaris 2.5.1 system and couldn't find any prototype for usleep

it seems they added the protypye to unistd.h in 2.6 because I don't have a protytype either, strangely enough I build fvwm on 2.6 and have users running on 2.6 and 2.5.1 and I've only had users get this problem on 2.6 ??

As I said before the problem is rather intermitent but I'll try to add thje protypete at see if it turns up again.