Consistent problems with gs, toolbar, pman under WinNT
Twan van der Schoot
Wed Jul 10 01:24:03 CEST 2002
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
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
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
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.
More information about the erlang-questions