Hi again,
On Fri, Sep 10, 2010 at 9:59 AM, Khadija EL MAHRSI
<[email protected]> wrote:
> Hello,
> making the change you suggested made the application block completely
> sending a bug report so I kept the old version.
Ok, it looks like the encapsulated exception causes problem when it
gets distributed in Mozart 1.3.2. We should therefore avoid its
distribution.
To see error messages, you could modify the
CreateRemoteStationaryObject such that is does NOT return the
exception, but displays it on the machine where it runs, like this:
local
RM = {New Remote.manager init}
in
fun {CreateRemoteStationaryObject Class Init}
functor RemoteCode
import Inspector
export result:Result
define
Result
%% create a stationary instance on the remote site
try
Result = {NewStat Class Init}
catch E then
Result = error
thread
{Inspector.inspect E}
end
end
end
AppliedFunctor = {RM apply(RemoteCode $)}
in
AppliedFunctor.result
end
end
(This is only a short-term solution. In a real application, you
certainly don't want to run to a remote machine to see an error
message...)
> The weird thing is that this warning sometimes appears and sometimes it
> doesn't (even though I don't recall changing anything) and in both cases I
> get the famous error:
>
> %********************** error in application *************
> %**
> %** Application of non-procedure and non-object
> %**
> %** In statement: {<Resource> getX(_<optimized>)})
>
This looks like the object was not successfully constructed, i.e.
something went wrong in the init method. As a consequence, instead of
calling "getX" on an object, it is erroneously called on a "failed
value" which was (for some reason) distributed as a "resource". (Sorry
if this sounds confusing.)
With the above change you should be able to see the original error message.
> I've noticed something, this warning appears if I click on the main.exe
> generated after ozc -x main.oz but if ran ./main using Cygwin the warning
> doesn't appear. Any explanation?
That's strange. Maybe it has something to do with different path settings.
>
>> I don't think this is related to threads. While threads themselves
>> cannot be distributed, objects that merely use threads should not
>> cause problems when distributed.
> Are you sure about this? because I don't want to change the class that uses
> threads at all.
I have tested a small example. I'm pretty sure that using a thread in
the constructor does not cause problems. When a mobile object is used
on a remote site, that thread will not magically be transferred to the
other machine, it just continues where the object was originally
started.
>
> I wanted to ask something about the class using threads. Since this class is
> going to be used by different instances created from some other class (which
> also use threads and which are stationary on the sites where they are
> created) distributed among many sites. Is this instace going to travel among
> the sites so that it can be used by all the instances that need it? If so,
> is the application going to work the same way as if it weren't distributed
> (because this is exactly what I want)?
>
Yes, by default the methods will run on the caller site and the
object's state will be synchronized between sites. Such a mobile
object may NOT use any sited entities like OS or QTk, though. And as
indicated above, the thread that was started in the constructor, will
not travel.
Cheers,
Wolfgang
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
