4 ms·

longjmp simply restores the machine registers (including PC and SP) and thus doesn’t respect any sort of unwind-protect, a concept unknown in C. unwind-protect

by gumby 3y ago

longjmp simply restores the machine registers (including PC and SP) and thus doesn’t respect any sort of unwind-protect, a concept unknown in C. unwind-protect is a more general form of the c++ raii (in fact c++ got raii from Common Lisp).

Findecanor 3y ago
`longjmp` does not restore the machine registers on all platforms. The C standard guarantees only the contents of variables marked `volatile`: anything above that is implementation-dependent. I think that MSVC++ longjmp actually does proper unwinding, calling destructors in C++ functions on the stack, but don't quote me on that. I think it is also dependent on the compiler flags.
gpderetta 3y ago
Implementing exception handling (with cleanup on unwind) on top of setjmp was not uncommon. GCC still does on some targets. But I'm sure you know this more than I do. I think that RAII is different from unwind-protect and other scope based cleanup (finally, defer, with) as it is tied to object lifetimes. The fact that automatic objects lifetimes are tied to scope is a nice feature, but RAII goes beyond that.
- gumby 3y ago
  Well lisps don’t really have destructors in the sense C++ does; objects go out of scope and become unreachable. So unwind-protect makes cleanup (closing a file, for example) explicit, which it has to be. I wouldn’t say RAII is “tied to object lifetime” except in its name; at least I think of it as every {} pair defining an unwind-protect with object creation/destruction being how it is effected by the programmer. Perhaps that is the same thing as you said, simply viewed from opposite sides. I do like the automatic nature of RAII, though implementing a whole class for it always feels clumsy to me even after doing it for decades.
  - gpderetta 3y ago
    What I mean is that if I add an instance of a class with a non trivial destructor from a container and later remove it, the destructor is automatically invoked. This is different from an unwind protect.
    - lispm 3y ago
      Lisp uses UNWIND-PROTECT to implement that. For example WITH-OPEN-FILE closes the file automatically when leaving its scope. (with-open-file (stream "hello.world") (read stream)) WITH-OPEN-FILE is a macro and expands into OPEN and CLOSE operations, protected by an UNWIND-PROTECT. Thus anything where a destructor would automatically clean things up is done in Lisp behind the scenes automatically using an UNWIND-PROTECT form.
      - gpderetta 3y ago
        That's again an example of cleanup associated with scope. I understand what you can do it with unwind-protect and friends. But the essence of RAII is more than that. In c++ if I add an opened file object to some collection and later remove it or destroy the collection, it is implicitly cleaned up. For example let's say you are implementing an n-way out of core merge: in c++ you would create a priority queue of files objects ordered by the front current from item. You pop the front file object read the item and, if the file is not empty, push it back into the queue. Cleanup is implicit by removing the file from the queue and not explicitly adding it back. On early exit (because of an error or exception) the queue is automatically destroyed and recursively all the file objects. There might be a way to implement this recursively with unwind-protect, but I think it is less natural. For example python has ExitStack, which in practice is an ad-hoc container that supports recursive cleanup of contained objects, but is still not as convenient as having all containers do proper cleanup.
    - kazinator 3y ago
      The object is not exactly removed from the container. It is removed from existence. The object in that situation resides in the container physically. It is constructed there and destroyed. It does not exist outside of the container afterwards, or at any other time. This is a low-level memory management strategy being conflated with object-orientation, that is alien to higher level languages.
oumua_don17 3y ago
>> in fact c++ got raii from Common Lisp I know and understand this is true. Can you point to any sources (projects, papers) that further substantiate this?
- gumby 3y ago
  No, but Tiemann might remember as I remember introducing him to unwind-protect (not that he invented RAII afaik, nor would claim to have)
- adrian_b 3y ago
  The concept of RAII has emerged gradually and it would be hard to pinpoint a moment for its appearance. I am not aware of any specific feature of RAII that has appeared in Common Lisp before other languages. The concepts of constructors and destructors have been introduced by C.A.R. Hoare in November 1965, in "Record Handling", a proposal for the extension of Algol. At that time, Hoare was using the Cobol terms, i.e. "record" for what later was named "object" and "record class" for what later, in Simula 67, was abbreviated to "class". All the "records" discussed by Hoare were allocated dynamically, in the heap. Constructor (Hoare, 1965-11): "In order to bring records into existence in the first place, the record class identifier should be used as if it were a function designator" Destructor (Hoare, 1965-11): "a standard procedure "destroy" is proposed, which takes as parameter a reference to a record, and which reverses the effect of having created that record" The next step towards RAII has been done by Bjarne Stroustrup in "C with Classes" in April 1980, when he made the invocation of the destructors implicit at the exit from a block, by introducing the special member function "delete" for this purpose. Despite the name, the 1980 "delete" member functions corresponded to what later, in C++, were renamed as destructors. So in 1980, RAII was complete, but it was not yet promoted as a universal strategy for managing resources. In 1980, Common Lisp did not exist. Most older Lisps did not have any concept similar with the Algol block, so it would have been impossible for them to invoke implicitly some cleanup functions at block exits. They relied only on the garbage collector, where there is no RAII in the Stroustrup sense, even if GC and RAII are alternative methods for avoiding the explicit invocations of "free", "close" and the like.
  - 3y ago

by gumby 3y ago

Findecanor 3y ago

`longjmp` does not restore the machine registers on all platforms. The C standard guarantees only the contents of variables marked `volatile`: anything above that is implementation-dependent. I think that MSVC++ longjmp actually does proper unwinding, calling destructors in C++ functions on the stack, but don't quote me on that. I think it is also dependent on the compiler flags.

gpderetta 3y ago

Implementing exception handling (with cleanup on unwind) on top of setjmp was not uncommon. GCC still does on some targets. But I'm sure you know this more than I do. I think that RAII is different from unwind-protect and other scope based cleanup (finally, defer, with) as it is tied to object lifetimes. The fact that automatic objects lifetimes are tied to scope is a nice feature, but RAII goes beyond that.

gumby 3y ago
Well lisps don’t really have destructors in the sense C++ does; objects go out of scope and become unreachable. So unwind-protect makes cleanup (closing a file, for example) explicit, which it has to be. I wouldn’t say RAII is “tied to object lifetime” except in its name; at least I think of it as every {} pair defining an unwind-protect with object creation/destruction being how it is effected by the programmer. Perhaps that is the same thing as you said, simply viewed from opposite sides. I do like the automatic nature of RAII, though implementing a whole class for it always feels clumsy to me even after doing it for decades.
- gpderetta 3y ago
  What I mean is that if I add an instance of a class with a non trivial destructor from a container and later remove it, the destructor is automatically invoked. This is different from an unwind protect.
  - lispm 3y ago
    Lisp uses UNWIND-PROTECT to implement that. For example WITH-OPEN-FILE closes the file automatically when leaving its scope. (with-open-file (stream "hello.world") (read stream)) WITH-OPEN-FILE is a macro and expands into OPEN and CLOSE operations, protected by an UNWIND-PROTECT. Thus anything where a destructor would automatically clean things up is done in Lisp behind the scenes automatically using an UNWIND-PROTECT form.
    - gpderetta 3y ago
      That's again an example of cleanup associated with scope. I understand what you can do it with unwind-protect and friends. But the essence of RAII is more than that. In c++ if I add an opened file object to some collection and later remove it or destroy the collection, it is implicitly cleaned up. For example let's say you are implementing an n-way out of core merge: in c++ you would create a priority queue of files objects ordered by the front current from item. You pop the front file object read the item and, if the file is not empty, push it back into the queue. Cleanup is implicit by removing the file from the queue and not explicitly adding it back. On early exit (because of an error or exception) the queue is automatically destroyed and recursively all the file objects. There might be a way to implement this recursively with unwind-protect, but I think it is less natural. For example python has ExitStack, which in practice is an ad-hoc container that supports recursive cleanup of contained objects, but is still not as convenient as having all containers do proper cleanup.
  - kazinator 3y ago
    The object is not exactly removed from the container. It is removed from existence. The object in that situation resides in the container physically. It is constructed there and destroyed. It does not exist outside of the container afterwards, or at any other time. This is a low-level memory management strategy being conflated with object-orientation, that is alien to higher level languages.

oumua_don17 3y ago

>> in fact c++ got raii from Common Lisp I know and understand this is true. Can you point to any sources (projects, papers) that further substantiate this?

gumby 3y ago
No, but Tiemann might remember as I remember introducing him to unwind-protect (not that he invented RAII afaik, nor would claim to have)
adrian_b 3y ago
The concept of RAII has emerged gradually and it would be hard to pinpoint a moment for its appearance. I am not aware of any specific feature of RAII that has appeared in Common Lisp before other languages. The concepts of constructors and destructors have been introduced by C.A.R. Hoare in November 1965, in "Record Handling", a proposal for the extension of Algol. At that time, Hoare was using the Cobol terms, i.e. "record" for what later was named "object" and "record class" for what later, in Simula 67, was abbreviated to "class". All the "records" discussed by Hoare were allocated dynamically, in the heap. Constructor (Hoare, 1965-11): "In order to bring records into existence in the first place, the record class identifier should be used as if it were a function designator" Destructor (Hoare, 1965-11): "a standard procedure "destroy" is proposed, which takes as parameter a reference to a record, and which reverses the effect of having created that record" The next step towards RAII has been done by Bjarne Stroustrup in "C with Classes" in April 1980, when he made the invocation of the destructors implicit at the exit from a block, by introducing the special member function "delete" for this purpose. Despite the name, the 1980 "delete" member functions corresponded to what later, in C++, were renamed as destructors. So in 1980, RAII was complete, but it was not yet promoted as a universal strategy for managing resources. In 1980, Common Lisp did not exist. Most older Lisps did not have any concept similar with the Algol block, so it would have been impossible for them to invoke implicitly some cleanup functions at block exits. They relied only on the garbage collector, where there is no RAII in the Stroustrup sense, even if GC and RAII are alternative methods for avoiding the explicit invocations of "free", "close" and the like.
- 3y ago