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

Reply via email to