Re: another way to shoot yourself in the foot?



On Tue, 24 Jun 2008 13:20:54 -0400, Robert A Duff wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> writes:

On Tue, 24 Jun 2008 07:59:35 -0700 (PDT), Adam Beneschan wrote:

I've probably lost the plot of this thread. But in regards to the
example, I think the example is "no". The semantics should be exactly
the same as if Interesting's body were simply "return X : T;". The
first extended return statement that raises an exception doesn't have
any effect, in terms of starting a new task or anything like that,
because the RM explicitly says that task activation doesn't occur
until after the function returns (6.5(7)).

OK, then the notorious problem of Ada 95, that a task cannot be
initialized, in the sense that upon initialization you could pass
parameters to it via a rendezvous, is still there.

The way to initialize tasks in Ada 95 and Ada 2005 is to pass
discriminants to the task.

It is a very limited way, and in any case semantically it is different from
initialization parameters. A parameter is not required to outlive
initialization, while a discriminant is. Logically discriminant is a
constraint, it is by no way a parameter.

Tasks finalization does not work either, because there is no destructing
functions ("malfunctions" to use the name Robert Duff suggested (:-))
anyway.

I'm not sure what the issue is, here. Masters wait for their dependent
tasks to terminate (or be "ready" to terminate -- at a terminate
alternative) BEFORE the task objects are finalized. So when a task
object is finalized, it is already terminated, so it doesn't make sense
to rendezvous with it.

Nope, it makes a lot of sense, but it just does not work. Because a task
rarely knows if it should complete. The enclosing object does not expect
its components to prematurely finalize themselves. It is just a bad design
turned upside down:

task type Foo is
Start_Up (...);
Shut_Down (...);
end Foo;

type T is new Ada.Finalization.Limited_Controlled with record
X : Foo; -- No chance to make this working
...

There is no other option than to use access to task instead:

type Foo_Ptr is access Foo;
type T is new Ada.Finalization.Limited_Controlled with record
X : Foo_Ptr; -- This is OK, but more C++ than Ada!
...

procedure Initialize (Obj : in out T) is
procedure Free is new Ada.Unchecked_Deallocation (Foo, Foo_Ptr);
begin
Obj.X := new Foo;
Obj.X.Start_Up (...);
exception
when others => -- We don't want it leaking, right?
Free (Obj.X); -- Probably this will hang, nevertheless...
raise;
end Initialize;

procedure Finalize (Obj : in out T) is
procedure Free is new Ada.Unchecked_Deallocation (Foo, Foo_Ptr);
begin
Obj.X.Shut_Down (...);
Free (Obj.X);
exception
when others =>
Free (Obj.X);
raise;
end Finalize;

A quite intrusive pattern, isn't it?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.



Relevant Pages

  • Re: another way to shoot yourself in the foot?
    ... end Foo; ... first extended return statement that raises an exception doesn't have ... It seems that an in-place initialization might result in n ... I think the ARG has recognized that the semantics need to be better ...
    (comp.lang.ada)
  • Re: LoadLibrary fails - one or more arguments are invalid
    ... > The error occurs during initialization but before DllMain gets called. ... > the construction of a class, the function foo() gets called (obviously pared ... > any members causes an access violation. ... > static struct Entry { ...
    (microsoft.public.dotnet.languages.vc)
  • Re: MDA Loader?
    ... written code yourself that causes managed code to be executed inside the ... initialization of a DLL, you may indeed want to heed the warning. ... using Microsoft-provided components that themselves cause the exception. ... note that the MDA exceptions are part of the debugger. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: LoadLibrary fails - one or more arguments are invalid
    ... "Ronald Laeremans " wrote: ... >> The error occurs during initialization but before DllMain gets called. ... >> TomR ... > How does foo get called before DLLMain is executed? ...
    (microsoft.public.dotnet.languages.vc)
  • Re: is such exception handling approach good?
    ... I agree with you that there is no exception thrown from constructor. ... there may be exception thrown from other initialization methods, ...
    (microsoft.public.vc.language)