Hi Boriss and all,
I have now a work-in-progress bugfix regarding pickles on Windows.
The problem is that the mechanism used for distinguishing between file
and socket descriptors is done using the FD_XXX macros. This is bad,
because the mechanism is not robust enough. Recently we are facing
problems on long-running server machines, because the file descriptor
handles are mistakenly used as socket descriptors, thus "send" is used
on them instead of "write" (or vice-versa), resulting in errors.
Of course, this bug also affects many other things than pickles - the
sockets and file io themselves, and many unexpected
distributed-programming failures.
The solution is obvious - use a dynamic-sized unordered set for the
socket descriptors. But - I need to know what are the choices for such
implementation. Of course I don't want to introduce problems by writing
my own hashtable implementation, so I'd like to use boost::unordered_set
or at least std::map (this would degrade performance a bit in heavy-IO
programs). But STD Lib is not used anywhere in Mozart, neither is boost,
so I'm reluctant to introducing a new dependency.
I think that this is a critical bug and I'd be glad if we could fix it
before releasing the next version.
Cheers,
Filip
PS: to be more specific, the error I'm getting is coming from
platform/emulator/components.cc line 325, and looks like:
%***************** Error: distributed programming ***************
%**
%** Write failed during save
%**
%** File: 'some_file'
%** Error: 'No error'
("no error" because components.cc uses "errno" for reporting, but since
the error comes from send(), it should be taking it from
WSAGetLastError, which I'm sure reports 10038 "Not a socket handle").
Later, the same call returns:
%***************** Error: distributed programming ***************
%**
%** Write failed during save
%**
%** File: 'some_file'
%** Error: 'Permission denied'
Which I think is because some other calls in between set errno to
"Permission denied".
So I think I'll fix the error reporting first and wait for your comments
regarding hashtable implementation.
F.
Dear Hackers,
We had a discussion here at UCL about future releases of Mozart, and
we would
like to have your opinion in order to take some decisions.
First, there are two main projects that will produces releases 1.4.0 and
1.5.0. These are MozDSS and GeOz. The numbers will depend on which one
releases first.
But, since we haven't released since July 2006 (version 1.3.2), we
wonder if
it is worthy to release 1.3.3 before MozDSS and-or GeOz. The point is
that no
major bug fixes has been added to the 1-3-0-fixes branch, but here
there are
some reasons in favour of doing the release:
- There is now support for windoze Vista. This is a very small fix
that is
already included in a new 1.3.2 installer for windowze, but it would
be good
to uniform the packages.
- The small fix in the oz script that calls the emulator, and that
concerns
spaces in files names, seems to have fixed an annoying bug for some time.
- The was an issue concerning the default behaviour of the OPI, where
different threads where launched with every "declare" statement. This fix
might be interesting mainly for students.
- A 1.3.3 release would be a would opportunity to close the
1-3-0-fixes branch
- Releasing is good to show that the community is still working on
Mozart/Oz
- Having a deadline for a release may force us to try to fix some
extra-small bugs
The strongest argument against the release would be that the amount of
fixes
is very small, and it might be enough to not release, but I'm not sure of
that. This is why I would like to discuss this in order to take a
decision.
Best,
Boriss
_________________________________________________________________________________
mozart-hackers mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
--
Filip Konvička
LOGIS, s.r.o.
tel. +420 556 841 100
mob. +420 736 758 714
_________________________________________________________________________________
mozart-hackers mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers