Consistent problems with gs, toolbar, pman under WinNT

[Twan van der Schoot]

Dear all,

after some trepidation I dare to rise an issue which has been mentioned in 
the release notes of R8B-0 and RB8-1 about, and I quote from the 
Readme-file: "4.1 Some graphical tools have problems on Windows. Pman may 
not start at the first attempt. Some other tools may give some error 
messages."

I'm sorry to say that the situation is graver than suggested by this note. 
 Repeated attempts to start, e.g. the toolbar do indeed finally succeed, 
taking a very long time to start.  But, alas, actually using any of the 
"graphical" tools invariable lead to a crash and an erlang dump!  What's 
more, the node on which gs has been started crashes and is left in an 
appearantly unrecoverable state, ouch.

I encountered this problem from RB8-0 on and I quickely reverted back to 
the R7B version which does not suffer from this problem.  But today I tried 
it again by installing and running R8B-1, to no avail.

The reason I now dare to raise the issue is that other people seem tp 
complain about the same problem, but on WinNT systems much much faster 
(1.8GHz systems) than my own system (a dual 133MHz processor system).

A number of symptoms of the problem indicates IMHO (a) synchronisation 
problem(s):
1. Repeately attempting to start the gs-system (e.g. by toolbar:start() ) 
does start the gs-system and the toolbar;
2. Actually using "successfully" started gs-based applications eventually 
do crash because the gs-kernel has died;
3. The same problem occurs on fast as well on slow systems;
4. The tcl/tk process starts nevertheless quite quickly, but shows the 
first window very late.

Alas, I'm not an expert on process creation and the plumbing of pipes in 
WinNT and I've no background information on the required level of 
compatibility with pipes on a SunOS or UNIX-like platform.

But the inspection of the windows specific C-code suggests that no specific 
measures have been taken to synchronise the creation of the various 
processes and pipes (As far as I can see the Erlang driver seems to work 
via the stdout and stdin pipes of the tcl/tk process instance) and the 
first use of these system resources.  No mutexs, no Win32 Events are used. 
 It looks like that the makers of the drivers c.a. (in 1996!) made some 
implicit assumption on the sequence of events, which now, somehow has 
changed.

On the other hand, I can completely be wrong :(

Nevertheless, I don't know what the priority of the MS WinNT/W2000 version 
of Erlang is in the Open Source strategy of Ericsson, but is structurally 
lags behind the "real" UNIX versions.  Normally it is not that big a 
problem, but I think that the debugger and the pman applications are 
essential tools and can hardly be missed.