Re: How to avoid unreferenced objects (mutexes etc)

["Matthew Heaney" <mheaney@on2.com>]

"Darren New" <dnew@san.rr.com> wrote in message
news:3C44CFBD.BC1ED52F@san.rr.com...
> Sure. Now Op can't act as an entry.

I don't understand this comment.  Op is a procedure, so by definition it
isn't an entry.


> The basic problem is that if I have something that says
>   x.boop
> and boop is an entry,

I don't understand this comment.  Is x a task object, protected object, or
something else?  How can boop be anything other than an entry?

> it can only call one specific piece of code. That
> one specific piece of code has to be the one that determines whether the
> code blocks.

Can you say Boop (X), and then implement operation Boop to have the behavior
you want?


> That's not guarding an entry. If T.op dispatches, then it can't be an
> entry. If it's an entry, I can't override it.

I don't understand this comment.  If you use the syntax
   T.op
then T must be a task (or protected object).  And in that case it's an
entry, and so of course it doesn't dispatch.

If you had said:  "If Op (T) dispatches" then I would understand your
question about whether it dispatches.  But you didn't, so I'm confused.

What's wrong with saying Op (T), and implementing Op as a primitive
operation of T?


> I can't do
>   select T.op or delay 10.0 ; yadda end select;
> and have T.op be one of two different pieces of code, for example.

This is a selective entry call.  So wrap it in a dispatching operation:

function Op (O : in out T; Timeout : Duration) return Boolean is
begin
   select
      O.T_Task.Op;
      return False;
   or
      delay Timeout;
      return True;
   end select;
end Op;

Now if you say:

   Timed_Out := Op (O, 10.0);

then you get blocking and dispatching.


> The problem I had was trying to build a library wherein the framework
> instantiates a number of tasks. Each task is provided by the user of the
> framework. (Think, for example, of someone writing multiple types of
> windows in a GUI framework.) Each task would need to respond to
> different events at different times (meaning selective accepts in the
> tasks)

Don't use selective accepts in tasks.  This is old-fashioned.  Rewrite your
tasks to make blocking calls to an internal protected object.  Have
operations communicate with the task by calling the protected object, which
wakes up the waiting task.