This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libfortran/30617] recursive I/O hangs under OSX



------- Comment #27 from dominiq at lps dot ens dot fr  2007-04-24 13:03 -------
> Please define "fixed".

For me "fixed"=="no hanging" period.

> You run an invalid program, 

Yes, I know, repeating that won't help!

> all you need is change your expectations what will happen.

Bugzilla has plenty of entries "ICE on invalid", I am just asking that "hanging
on invalid" is not brushed aside just because it does happen on a platform some
people don't like.

> It is the same as if you write
> pthread_mutex_t m;
> pthread_mutex_init (&m, NULL);
> pthread_mutex_lock (&m);
> pthread_mutex_lock (&m);
> The deadlock might be detected or might not, at which point it would hang.

As far as I can tell, without knowledge of the 'pthread_mutex' mechanism, the
problem does not occur at this level, but at the level of:

pthread_mutex_unlock (&m)
pthread_mutex_unlock (&m)

where the first 'unlock' releases all the previous locks dealing with the same
unit number, leaving the second 'unlock' "waiting for something that is not
coming".  Something like:

pthread_mutex_init (&m, NULL);
pthread_mutex_lock (&m);
pthread_mutex_init (&m1, NULL);
pthread_mutex_lock (&m1);
...
pthread_mutex_unlock (&m1)
pthread_mutex_unlock (&m)

is working (see comment #19), so probably if &m refers to some "event" and not
to some "unit number" (not being ashamed to show my ignorance) the problem
would disappear.

I think the following answer from

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d3caadeb9083808e/78c9e65c8b4f930e?lnk=gst&q=recursive&rnum=11#78c9e65c8b4f930e

summarize the discussion

Even if this restriction on recursive input/output is
unnecessary or undesireable, it is, nonetheless, a part
of the Fortran 2003 standard.

Note the "unnecessary or undesireable", leading me to the following comments:

(1) the use of recursive I/O can be detected at run time: xlf does it;
I guess that a second locking of '&m' would not be too difficult to detect and
I don't buy the efficiency argument at this level (gfortran did not strike me
as being any faster than xlf on I/O operations);

(2) the behavior, however "processor" (fortran meaning) dependent it is, should
be platform independent: just imagine the port to OSX of a 100kloc code where
one such recusive I/O used for debuging on Linux (it works) has been left;

(3) I repeat that I am not asking for an immediate fix, only that the problem
is not forgotten due to the 'invalid' label.

Anyway, thanks for the answer.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]