SourceForge has been redesigned. Learn more.
Close

#60 two things when using signals

open
nobody
nuisance (37)
5
2004-11-10
2004-11-10
aki
No

in freeglut-2.2.0:

1)
when signal arrives, select() in fgSleepForEvents() returns
an error which is always printed out using fgWarning().
It'd
be wiser to print nothing when errno == EINTR to avoid
excess flood.

2)
when doing glutPostRedisplay() or setting idlecallback
or whatever in the signal handler, a race condition exists
in fgSleepForEvents() between the if and the actual select
call. pselect() and sigprocmask() can be used to avoid
the problem (if the operating system has pselect. in linux
pselect is implemented using sigprocmask & select,
but at least using it makes the problem less likely).

a patch is attached.

Discussion

  • aki

    aki - 2004-11-10

    signal safety patch

     
  • Richard Rauch

    Richard Rauch - 2004-11-13

    Logged In: YES
    user_id=854844

    Since freeglut strives to be portable, I think that it would
    be unwise to use a non-standard function such as pselect().
    (There is no man-page for it on my system, nor does a 'grep
    -r' for it turn it up in /usr/include.)

     
  • Sven Panne

    Sven Panne - 2004-12-31

    Logged In: YES
    user_id=50298

    Fixed EINTR behaviour. A small plea: Please use different bug
    reports for different bugs, it makes bookkeeping much easier and
    clearer.

    Regarding the race condition: I'll have a look at that later. Using an
    OS-specific call like pselect would be no problem, autoconf is our
    friend here. :-)

     
  • Richard Rauch

    Richard Rauch - 2004-12-31

    Logged In: YES
    user_id=854844

    Well, sigprocmask() is standard. pselect() is not. So
    you'll have to write a standard version anyway. Why throw
    in a non-portable version? Just solve it once.

    I actually do not see how the race condition is an issue
    for the library, though. I think that it is more useful to
    allow the application to get signals (and make the app.
    responsible for handling them sanely!). Perhaps I am missing
    something? When I commented before, I was more inclined to
    believe that this was a problem, but not it looks like a
    non-problem to me.

    Perhaps someone can enlighten me with an example that cannot
    be reliable without the GLUT event loop locking out
    signals?

     

Log in to post a comment.