Martin Stjernholm wrote:
"Stephen R. van den Berg" srb@cuci.nl wrote:
Ideal methods are threadsafe, and should be able to handle themselves in all cases.
Hardly relevant since pike isn't a toy for language purists. We don't want to add thread safety in every function since it adds complexity and overhead (and besides I don't see any way for the language to enforce it without seriously crippling thread support). The same goes for wrappers to avoid cycles.
I think we're talking past each other here. I'm not saying that the language should enforce thread safety or anything else. I'm just saying that someone writing a class, should try to make the class threadsafe.
It's not hard to deal with these implicit properties if one only is aware of them. It's much more efficient and imho also easier to treat them as properties objects might or might not have, just like the existence and type of any identifier.
Pike isn't alone in this. At least C++ and Java allow similar implicit properties in object behavior, and I'd wager most other real world OO languages do too.
Yes, like I said above, that's a Good Thing. But that doesn't mean that someone writing a class should avoid these special properties if at all possible without excessive cost.
Calling the destructors can be done, without freeing the actual memory; /.../
No. Consider the case when there's an array, mapping or something else that indirectly might contain objects. You have to free it to be sure that the appropriate objects are destructed.
I disagree (but, most likely, I still have the privilege to do this, because I'm not aware of the exact implementation Pike picked). Even if there's an array, mapping or something else that indirectly might contain objects; then it is not necessary to free this structure, it is only required to *traverse* this structure scouting for objects which have actual destructors defined. The actualy memory footprint can be left alone.
But, for all I know, traversing the structure might be more difficult than simply freeing it.
Besides, given the fact that programmers usually only use scopes within a function to limit the scope of a variable because they want to save memory, /.../
Actually, that's not how I commonly use it. Most of the time I use it to limit the visibility of the identifier to the narrowest possible scope. In these cases I don't much care about when the memory really is released.
Ok, another possibility. I do this myself as well, but it's a practice I don't see a lot by anyone else.
Anyway, the memory has to be freed sooner or later anyhow, so the only speed lost would be due to slightly larger code and some more twiddling of the stack pointer, and I think that's negligible.
I'd say the same (without knowing as much about the Pike implementation).
Note that inner functions make it a bit complicated to implement popping at the end of scopes. Consider this case:
That I realise. But that's a problem with actually freeing the memory, not with calling the destructors.
Sorry, but the same goes for destruction itself. It's trivial to adapt my example so that there's an object that shouldn't be destructed when the block is exited.
Undoubtably true, but this discussion is not that important, since it will follow whatever constraints are given for correct operation. I just want to destruct objects which lose scope. If the object should be longer lived because of some reason, then so be it, then don't call the destructor yet.
Ok, since we agree on the target. Any ideas on where to look in the Pike source?
Assuming that my suggestion from the other mail works, it's docode.c, interpret_functions.h, language.yacc and probably a bunch of others. Welcome to the world of the compiler and interpreter internals. ;)
I'm not afraid. I did GCC development for more than a year, quite intensively in 1993-1995 (developing x86 register passing (coded in 14 days) and ending up fixing more collateral damage than I ever bargained for, all needed to support the 14 day hack for register passing).
(Moving the discussion to the pike devel list since it's clearly about pike development now.)
Ok, I just subscribed. On a related note, can I have write access to the Pike CVS repository? I agree to the rules. I promise to be a good boy. My username on the lysator.liu.se system for CVS is _cvs_stephen I'm already using it in the ChiliMoon project. I presume it can be reused for Pike. I'd need the CVS coordinates of the repository. I also wonder why the codelibrarian on lysator doesn't show Pike?
To mast: Yes, I know that many of my suggested patches to Roxen have the appearance of being a bit shortsighted. That's not usually my practice of doing things. This behaviour is driven by the fact that (over the years) I've noticed that Roxen is slow in responding to bug reports/patch suggestions. So in order to make the chance of acceptance high, I minimise the change, so it's more easily understood. The other reason is that changes which have minimal impact on existing code, allow me to maintain long-term diff-versions of Roxen, without the need to check for conflicts every time the master source changes. Changing more to get better code (designwise), makes for larger exposure to change-conflicts. This is bad if you know that some changes will not get in for at least three years. In ChiliMoon you'll eventually be able to see what the remaining patches should have looked like (the ugly DB-patches you're still sitting on, are next on the list now (since Pike has been adapted now :-)).
I think we're talking past each other here. I'm not saying that the language should enforce thread safety or anything else. /.../
Sorry, I didn't finish my chain of reasoning: If the language doesn't enforce it then the implicit properties are there anyway, whether you want them to or not. If you make your class thread safe and noncyclic you still have to say it is so in the doc, since other classes can be different.
But, for all I know, traversing the structure might be more difficult than simply freeing it.
Right on the money. It's in fact quite a bit more work since you have to keep track how many times you've visited each object through different reference chains, and then afterwards go through those objects where this count is equal to the total refcount and only act on those.
On a related note, can I have write access to the Pike CVS repository? I agree to the rules. I promise to be a good boy.
Sure. Please be careful. Welcome to the gang!
My username on the lysator.liu.se system for CVS is _cvs_stephen I'm already using it in the ChiliMoon project. I presume it can be reused for Pike.
No, Pike has a server of its own, pelix.ida.liu.se.
I'd need the CVS coordinates of the repository. I also wonder why the codelibrarian on lysator doesn't show Pike?
Because it's at the pike site: http://pike.ida.liu.se/development/cvs/browse.xml
To mast: Yes, I know that many of my suggested patches to Roxen have the appearance of being a bit shortsighted. That's not usually my practice of doing things.
Good to hear.
This behaviour is driven by the fact that (over the years) I've noticed that Roxen is slow in responding to bug reports/patch suggestions.
Very true. It's due to that the time allocated to WebServer maintenance has long ago reached zero (besides the work driven by the commercial products and paying customers), and at least I got plenty of more fun things to occupy my free time with. :\
So in order to make the chance of acceptance high, I minimise the change, so it's more easily understood.
Unfortunately the effect was exactly the opposite: In many cases there was just a very brief description of the problem and a patch that looked odd. There's no way I apply something that isn't clean and future safe, and I also don't apply stuff I don't understand fully. A test case that exposes the problem is much more helpful.
The other reason is that changes which have minimal impact on existing code, allow me to maintain long-term diff-versions of Roxen, /.../
Understandable.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-06-14 03:00: Subject: Re: scopes and destructors
Martin Stjernholm wrote:
"Stephen R. van den Berg" srb@cuci.nl wrote:
Ideal methods are threadsafe, and should be able to handle themselves in all cases.
Hardly relevant since pike isn't a toy for language purists. We don't want to add thread safety in every function since it adds complexity and overhead (and besides I don't see any way for the language to enforce it without seriously crippling thread support). The same goes for wrappers to avoid cycles.
I think we're talking past each other here. I'm not saying that the language should enforce thread safety or anything else. I'm just saying that someone writing a class, should try to make the class threadsafe.
It's not hard to deal with these implicit properties if one only is aware of them. It's much more efficient and imho also easier to treat them as properties objects might or might not have, just like the existence and type of any identifier.
Pike isn't alone in this. At least C++ and Java allow similar implicit properties in object behavior, and I'd wager most other real world OO languages do too.
Yes, like I said above, that's a Good Thing. But that doesn't mean that someone writing a class should avoid these special properties if at all possible without excessive cost.
Calling the destructors can be done, without freeing the actual memory; /.../
No. Consider the case when there's an array, mapping or something else that indirectly might contain objects. You have to free it to be sure that the appropriate objects are destructed.
I disagree (but, most likely, I still have the privilege to do this, because I'm not aware of the exact implementation Pike picked). Even if there's an array, mapping or something else that indirectly might contain objects; then it is not necessary to free this structure, it is only required to *traverse* this structure scouting for objects which have actual destructors defined. The actualy memory footprint can be left alone.
But, for all I know, traversing the structure might be more difficult than simply freeing it.
Besides, given the fact that programmers usually only use scopes within a function to limit the scope of a variable because they want to save memory, /.../
Actually, that's not how I commonly use it. Most of the time I use it to limit the visibility of the identifier to the narrowest possible scope. In these cases I don't much care about when the memory really is released.
Ok, another possibility. I do this myself as well, but it's a practice I don't see a lot by anyone else.
Anyway, the memory has to be freed sooner or later anyhow, so the only speed lost would be due to slightly larger code and some more twiddling of the stack pointer, and I think that's negligible.
I'd say the same (without knowing as much about the Pike implementation).
Note that inner functions make it a bit complicated to implement popping at the end of scopes. Consider this case:
That I realise. But that's a problem with actually freeing the memory, not with calling the destructors.
Sorry, but the same goes for destruction itself. It's trivial to adapt my example so that there's an object that shouldn't be destructed when the block is exited.
Undoubtably true, but this discussion is not that important, since it will follow whatever constraints are given for correct operation. I just want to destruct objects which lose scope. If the object should be longer lived because of some reason, then so be it, then don't call the destructor yet.
Ok, since we agree on the target. Any ideas on where to look in the Pike source?
Assuming that my suggestion from the other mail works, it's docode.c, interpret_functions.h, language.yacc and probably a bunch of others. Welcome to the world of the compiler and interpreter internals. ;)
I'm not afraid. I did GCC development for more than a year, quite intensively in 1993-1995 (developing x86 register passing (coded in 14 days) and ending up fixing more collateral damage than I ever bargained for, all needed to support the 14 day hack for register passing).
(Moving the discussion to the pike devel list since it's clearly about pike development now.)
Ok, I just subscribed. On a related note, can I have write access to the Pike CVS repository? I agree to the rules. I promise to be a good boy. My username on the lysator.liu.se system for CVS is _cvs_stephen I'm already using it in the ChiliMoon project. I presume it can be reused for Pike. I'd need the CVS coordinates of the repository. I also wonder why the codelibrarian on lysator doesn't show Pike?
To mast: Yes, I know that many of my suggested patches to Roxen have the appearance of being a bit shortsighted. That's not usually my practice of doing things. This behaviour is driven by the fact that (over the years) I've noticed that Roxen is slow in responding to bug reports/patch suggestions. So in order to make the chance of acceptance high, I minimise the change, so it's more easily understood. The other reason is that changes which have minimal impact on existing code, allow me to maintain long-term diff-versions of Roxen, without the need to check for conflicts every time the master source changes. Changing more to get better code (designwise), makes for larger exposure to change-conflicts. This is bad if you know that some changes will not get in for at least three years. In ChiliMoon you'll eventually be able to see what the remaining patches should have looked like (the ugly DB-patches you're still sitting on, are next on the list now (since Pike has been adapted now :-)). -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless). "It has been said that the only standard thing about all UNIX systems is the message-of-the-day telling users to clean up their files." -- SysV.2 manual
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum -
Stephen R. van den Berg