Re: [announcement] SYSAPI and SYSSVC for Windows

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Ekkehard Morgenstern wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> The thing I mentioned was a large automation system for a roller
>> dynamometer.
> 
> What do you need Windows NT for in this application?

Because it is a part of the customer requirement.

>> > Why not use message queues and asynchronous I/O internally and stuff?
>> 
>> It uses all that. The problem is [very simplified] that two threads which
>> require approximately same number of time quants per second, get it under
>> NT, while under XP the balance looks like 8/1, causing stalling of a
>> queue. Boosting the priority of some of the threads solves the problem,
>> although leaving a feeling of great discomfort. We have no time for any
>> scientific researches concerning XP, so we are just waiting for the
>> Service Pack 1000, Longhorn, Devilhoof, whatsoever! (:-))
> 
> If you want me to take a look at the source, just e-mail me.

Thank you, but firstly it is a proprietary code, and secondly it requires a
lot of special hardware.

> I'm sort of an expert for concurrent programming, so I might be able to
> show you how to do it on 2000 and XP without any performance problems.
> 
> Normally, when you get a timing dependency, you have a design problem.

Windows is the actual design problem, and C++ too.

> Windows never had predictable timing, but that's another story, basically
> you cannot rely on precise timing. And for almost all applications, you
> don't ever need it if you take some precautions and use the right design.
> 
>> > However, you must not terminate the process forcefully. Under some
>> > conditions, the DLL cleanup is not done properly, but this is
>> > documented well in the Windows API documentation.
>> 
>> Yes, this is what I mean - better reboot the box, if a process crashes,
>> and never ever think to use TerminateProcess...
> 
> Design your application such that it does not depend on DLL cleanup.

The problem is to tell the customers, that *their* applications should be
designed so that *our* DLLs and hardware drivers would not stray into an
unpredictable state.

>> > A desire in a "ReleaseMutexAndWaitForSingleObject" function smells
>> > like bad multithreading design to me. What is it that you want to
>> > achieve with that?
>> 
>> To avoid race conditions. Because, it is c.l.a, it is worth to mention
>> how Ada did solve this, it introduced the requeue-statement.
> 
> Race conditions never happen with properly designed multitasking apps.

Yep, a properly designed application also works properly! (:-))

> For example, use the Event objects in Windows to signal conditions and
> avoid circular dependencies between data producers and consumers.
[...]
> If you implement your own message queues on Windows, use an Event object
> and a message list (protected by a mutex semaphore). Make the Event object
> manual-reset.

A manual reset event only needed when there could be more than one task
waiting for the event.

>> Alternatively one could switch to C++ approach, though deriving all
>> exceptions from the same base.
> 
> btw, that could be simply implemented into Ada as:
> 
>     type my_exception is new exception with
>     record
>            ...
>     end record;
> 
> So, exception would just have to be a tagged type.

Really? Consider this:

procedure Funny is
   Bomb : aliased Data;
   type Explode is new exception with record
      What : Data_Ptr;
   end record;
begin
   ...
   raise Explode'(What => Bomb'Unchecked_Access);
end Funny;      

Now you are in an exception handler with an exception of a type which was
already finalized!

Observe that the following is absolutely legal and works in Ada:

procedure Test
   procedure Funny is
      A : exception;
   begin
      raise A;
   end Funny;      
begin
   Funny;
exception
   when others =>
      null; -- Handling gone with the wind A
end Test;

See the difference?

> In a subprogram declaration, you could write perhaps:
> 
>     procedure f( ... ) raise my_exception;
> 
> However, what to do with exceptions raised by the runtime system?

One should deal with classes of exceptions. Ada run-time system would define
a class of run-time exceptions automatically inherited by any subroutine,
because all them are declared on the context of the package System.

> You would also have to write then:
> 
>     procedure f( ... ) raise my_exception, Constraint_Error;
> 
> for example. The compiler could analyse possible locations for
> constraint errors, etc., and then complain if Constraint_Error etc.
> are missing from the explicit exception declaration contract.

No, it would be:

   procedure f( ... ) raise ..., not raise Data_Error;

The compiler checks that Data_Error cannot propagate out of f.

> To declare exception type ranges, one could write:
> 
>     xcpt_a : exception;
>     xcpt_b : exception;
>     type my_xcpts is ( xcpt_a, xcpt_b );
> 
> or
>     type my_xcpts is ( xcpt_a : exception, xcpt_b : exception );
> 
> For the runtime system this could mean, there'd be a new runtime
> exception range called "runtime_exceptions".

In Ada ranges are not first-class objects. Alas. Then range is not a type,
it is a value. Then to be usable (in a case-statement) it has to be static.
And so on...
 
>> Work-around is the worst possible thing for an interface.
> 
> Depends really on how you do it. Normally you don't let work-arounds
> show up in the interface (in Ada: in the spec).

This is what I meant. Consider an interface specifying API for drawing
objects on device contexts. This clearly requires multiple dispatch: on the
object type and on the device type, which is not supported by the language.
End of story.

> C++ is well-defined also, btw. There's already a number of ISO standards
> for C and C++,

A *number of* standards, fascinating! (:-))

> and they fulfill the same purpose as the Ada rationale.
> Also, Bjarne Stroustrup's C++ books are also valuable when dealing with
> the language, since he invented it.
> 
>> > Hah, you just need to "downgrade" your design a bit and make it
>> > simpler, not as fancy as you would with C++, and boom you get along
>> > well with Ada.
>> > :)
>> 
>> In fact, it is the opposite. Ada's approach to OO is much more advanced
>> and consistent than C++'s one. So one need to downgrade switching to C++.
> 
> Ada 95 is a simple, light-weight programming language compared to C++.
> 
> C++ provides almost any OO facility that can be thought of,

Come on! C++ does not have:

1. multiple dispatch;
2. dispatch on function result;
3. dispatch on access types;
4. differentiation between class-wide and specific types;
5. functions returning class-wide objects on the stack;
6. streaming / object factory support ('Input, 'Output attributes in Ada);
7. formal derived type parameter for generics;
...

> I've not completed my Ada studies yet, and I'm still learning, but
> from what I've seen, OO programming is very restricted when compared to
> C++. However, this must not necessarily be bad.
> 
> For example, in my SYSSVC package, I've used procedures of the form
> 
>     type T is limited private;
>     procedure f( O : in out T );
>
> However, when T has a field that I need to take the address of within
> the procedure f(), it isn't possible.

Why? The following is OK:

   type T is limited private;
private
   type T is limited record
      I : aliased Integer;
   end T;

   procedure F (O : in out T) is
      type I_Ptr is access all Integer;
      O_I : I_Ptr := O.I'Access;
   begin
      ...

> I tried various things and ended
> up with using an access value:
> 
>     type T is limited private;
>     type T_Ptr is access T;
>     procedure f( O : in T_Ptr );
>
> Then it was possible to create an access to a member of T within the
> procedure.
> 
> This struck me as weird. Can you explain that?

There are two things, the first one is that to get an access one need an
aliased object, the second is the accessibility checks, protecting you from
dangling pointers. It is not clear what it was in your case. Probably it
was:

   procedure F (O : in out T) is
   begin
      ... O'Access; -- Error

This won't compile because of the first reason. Unlikely to C++, in Ada,
only aliased objects can be accessed via pointers. This allows the compiler
to better optimize the code. In rare cases, because pointers should be
avoided anyway, you have to inform the compiler that the object is aliased.
"Aliased" is the keyword for that. Objects of some types are always
aliased:

   type T is tagged limited ...;
   procedure F (O : in out T) is
   begin
      ... O'Access; -- OK, tagged objects are aliased

And finally, if you want to get a pointer in F, then probably

   procedure F (O : access T);

is reasonable.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de