Hi Filip,
Thanks for your reply. We were discussing your proposal yesterday and we also
agree that it would be very good to include this fix before releasing. Some
observations bellow.
Filip Konvička wrote:
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.
Since this is a bug mainly concerning windows, be sure that the fix you add is
within the #ifdef WINDOWS ... #endif marks
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.
True. It wouldn't be nice to add new dependencies. But as far as we know, the
code of boost and std are freely available, so you could just add the code of
what you need into the Mozart sources. Just be sure to put the corresponding
notes to be compliant with their license.
I think these fixes should go first to the mozart-1-3-0-fixes branch, and then
you merged them to the trunk.
thanks for the contribution
Boriss
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
_________________________________________________________________________________
mozart-hackers mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
