Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug or feature? #8045

Closed
vicuna opened this issue Mar 6, 2003 · 1 comment
Closed

Bug or feature? #8045

vicuna opened this issue Mar 6, 2003 · 1 comment
Labels

Comments

@vicuna
Copy link

vicuna commented Mar 6, 2003

Original bug ID: 1574
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

I'm not sure whether this is a bug or a feature.

I need to save the state of the Xcaml session between CGI
executions. Thinking in terms of Jserv-compliant
implementation, i used a Weak.Make(...).t hashtable to store
session data, so that old and no longer used data might be
automatically reclaimed by the GC. However, I found that
this implementation is buggy, because when I marshal and
unmarshal the weak hashtable, I always get an empty
hashtable back. Why is this?

I made a switch to Hashtbl.Make(...).t and now the session
handling in Xcaml works fine, except that there is no
automatic garbage collection. All other code, except for
minor modifications due to incompatibilities between the
output signatures of Hashtbl.Make and Weak.Make, has been
left untouched.

One more remark concerning the Weak.Make functor. Why in the
world are Hashtbl.Make and Weak.Make incompatible? It is
only natural to think of the second as a particularly clever
implementation of the first. Besides, the two modules are so
similar that really deserve to have the same signatures. I
strongly encourage the Caml Masters to think this over. Of
course, I could reimplement the Weak.Make functor in a Weak2
module for the ocamllib-addons package, but is it worth it?

Alex

@vicuna
Copy link
Author

vicuna commented Mar 7, 2003

Comment author: administrator

On Friday, March 7, 2003, at 12:13 AM, alex@baretta.com wrote:

I'm not sure whether this is a bug or a feature.

I need to save the state of the Xcaml session between CGI
executions. Thinking in terms of Jserv-compliant
implementation, i used a Weak.Make(...).t hashtable to store
session data, so that old and no longer used data might be
automatically reclaimed by the GC. However, I found that
this implementation is buggy, because when I marshal and
unmarshal the weak hashtable, I always get an empty
hashtable back. Why is this?

I'm not sure I understand what you are doing. Are you
marshalling the weak hash table by itself, or as part of a
bigger data structure ?

One more remark concerning the Weak.Make functor. Why in the
world are Hashtbl.Make and Weak.Make incompatible?

Weak hash tables were originally designed for hash-consing.
In this context, it doesn't make much sense to have key-value
pairs in the hash table: the hash table must be self-keyed.
Moreover, self-keyed weak hash tables are more efficient and
easier to implement. Also, the binding-order properties of
normal hash tables would not be satisfied by weak hash tables.

It is
only natural to think of the second as a particularly clever
implementation of the first. Besides, the two modules are so
similar that really deserve to have the same signatures. I
strongly encourage the Caml Masters to think this over.

If anything, we should change the Hashtbl.Make hash tables
to be self-keyed too. But that would in turn complicate the
interface of the generic hash tables...

Of
course, I could reimplement the Weak.Make functor in a Weak2
module for the ocamllib-addons package, but is it worth it?

I think there are already several implementations of key-value
weak hash tables out there...

-- Damien

@vicuna vicuna closed this as completed Mar 11, 2003
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant