SCOOP - Pass Objects from Region-to-Region

27 views
Skip to first unread message

Larry Rix

unread,
Feb 25, 2020, 8:50:54 AM2/25/20
to Eiffel Users
I think I am starting to "get" some of SCOOP—it's about Regions and Processors.

Each code pattern is about preserving the barriers between Regions and their Processors.

Passing objects across these barriers have a misunderstood bit on my part.

For example: If I have a routine call with a 'a_arg: separate STRING', I do something as 'my_obj.call ({separate STRING} "my_string")' and all is well!

I can also use a pattern to that incoming string from another Region into a string for my objects local Region with something like 'create l_local_string.make_from_separate (a_arg)', which creates a new STRING in my local Region that I can pass around and use freely in the local Region of my object.

What I am not yet seeing is—how do I convert more complex objects passed in as separate objects from other Regions and create a local "copy" for the local Region of the receiving object?

Gachoud Philippe

unread,
Feb 25, 2020, 9:01:18 AM2/25/20
to eiffel...@googlegroups.com
Hi Larry,

probably some more capable of SCOOP could understand and answer you better than me, but I'm trying anyway.

As far as I understood your question, your question is to create a twin from a separate object to a non separate one, am I correct?

Maybe it helps

l_horse: HORSE
l_horse_sep: separate HORSE

create l_horse -- goes to the REGION of the current class (or current instance of the current CLASS)
create l_horse_sep -- creates a new REGION

so you could do something like

create l_horse.make_from_separate (l_horse_sep)

as

HORSE
    make (other: separate like Current)
       do
            id := other.id
            position := other.position
       end

not tested...

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/ae54c5db-9e7b-4c88-8de1-cc90be13d10d%40googlegroups.com.


--
**********************************************
Philippe Gachoud
Puerto Williams 6657
Las Condes
Santiago de Chile
+56 934022210
ph.ga...@gmail.com
**********************************************

Gachoud Philippe

unread,
Feb 25, 2020, 9:04:12 AM2/25/20
to eiffel...@googlegroups.com
As a complement, the READABLE_STRING_32.make_from_separate does a similar job, I don't think the make_from_separate or set_from_separate would be different than any other make_from_other, but dealing with exclusive access

Jocelyn Fiat

unread,
Feb 25, 2020, 9:12:21 AM2/25/20
to Eiffel Users
Hi,

You may also look at the library  $ISE_EIFFEL/unstable/library/scoop_patterns especially the examples/sed_container that demonstrates the use of CP_SED_CONTAINER [G]





--
Jocelyn
------------------------------------------------------------------------
Eiffel Software
https://www.eiffel.com
Customer support: https://support.eiffel.com
User group: https://groups.google.com/forum/#!forum/eiffel-users
------------------------------------------------------------------------

Larry Rix

unread,
Feb 25, 2020, 9:12:52 AM2/25/20
to Eiffel Users
image.png

Gachoud Philippe

unread,
Feb 25, 2020, 9:23:19 AM2/25/20
to Eiffel Users
Does my answer not help you?

do
     Current.url := a_image.url -- Current can be removed but for the example
     Current.extension := a_image.extension
     ......
end

as I don't know your PE_IMAGE_FILE class

On Tuesday, February 25, 2020 at 11:12:52 AM UTC-3, Larry Rix wrote:
image.png

Larry Rix

unread,
Feb 25, 2020, 9:37:39 AM2/25/20
to Eiffel Users
Good morning! 

The PE_IMAGE_FILE is of no real consequence. It is just an Object (Class) and could be ANY-thing at all.

Larry Rix

unread,
Feb 25, 2020, 9:49:13 AM2/25/20
to Eiffel Users
Is there a specific routine on a specific class I need to look at?

I have both SED_CONTAINER_EXAMPLE and CP_SED_CONTAINER open and looking at them.

That stated—I do see the require 'execution_completed: a_server.completed' on 'wait_for_server_completion', which appears to be a "wait condition" use of the require contract. I think this very relevant to my needs.

Jocelyn Fiat

unread,
Feb 25, 2020, 9:49:37 AM2/25/20
to Eiffel Users
To add more information to my previous answer

From the library  $ISE_EIFFEL/unstable/library/scoop_patterns
you can use CP_SED_CONTAINER [G] 
The principle is to "import" from another scoop processor a serialized representation of the object.
Quite similar to the `make_from_separate` from STRING.

See the example examples/sed_container for more information.

On Tue, Feb 25, 2020 at 3:37 PM Larry Rix <lar...@moonshotsoftware.com> wrote:
Good morning! 

The PE_IMAGE_FILE is of no real consequence. It is just an Object (Class) and could be ANY-thing at all.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

Larry Rix

unread,
Feb 25, 2020, 10:27:01 AM2/25/20
to Eiffel Users
On Tuesday, February 25, 2020 at 9:49:37 AM UTC-5, Jocelyn Fiat wrote:
To add more information to my previous answer

The principle is to "import" from another scoop processor a serialized representation of the object.


THERE IT IS! 

Larry Rix

unread,
Feb 25, 2020, 10:48:02 AM2/25/20
to Eiffel Users
This spurs an observation.

The mechanism seems simple enough:

1. Serialize an object to a string representation.
2. Use the string representation to create a new string object in the Target Region.
3. Constitute (deserialize) a new object in the target Region from the newly created string object.

Serialization followed by Deserialization for the purpose of transferring an ANY-object across Regional SCOOP boundaries seems to present several undesirable matters:

1. The process is relatively slow, whereas reference passing (non-SCOOP) is very fast.
2. There is the potential problem of keeping "object copies" synchronized both in their data and possibly in view of polymorphism, yes?
3. Perhaps this is where creating "wait-states" and the danger of merging threads comes into play?

In my case for the present need—the serialization model will work fine because the Sending (Source) Region does not need the sent object back, nor does it do any further processing on the object it is sending. It's really just adding the object to a queue for processing once the Receiving (Target) Region is ready for it.



Larry Rix

unread,
Feb 25, 2020, 10:57:08 AM2/25/20
to Eiffel Users
This also makes me wonder why one could not just

1. Receive a reference from another SCOOP Region
2. Create a twin of it (as long as it can be twinned)
3. Give the new Recipient SCOOP Region-Process control over the newly minted (twinned) reference.

To put it more succinctly—within a call of 'my_object (a_arg: separate ANY)' we find code like:

'a_local_thing := a_arg.twin_from_separate'

So—you're not just creating a 'twin' of a thing, you're presuming the thing is in a separate Region with its own Processor and the goal is to make a twin (copy) of the other Regions object and give control of the twinned object to the new Target Region and its Processor.

Yes?

Larry Rix

unread,
Feb 25, 2020, 11:00:17 AM2/25/20
to Eiffel Users

'a_local_thing := a_arg.twin_from_separate'


Actually—I did this notation wrong.

'l_local_thing := a_arg.twin_from_separate'

where

my_feature (a_arg: separate ANY)
   
-- blah-comment ...
local
   l_local_thing
: like a_arg
do
   l_local_thing
:= a_arg.twin_from_separate
   
...
end

 

Gachoud Philippe

unread,
Feb 25, 2020, 11:11:29 AM2/25/20
to eiffel...@googlegroups.com
Another observation I can do is that your comment could be welcome into the sed_container class to understand what it does and whats its purpose.

Thx anyway for the feeds!

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

r...@amalasoft.com

unread,
Feb 25, 2020, 11:22:57 AM2/25/20
to eiffel...@googlegroups.com
Hi Larry
Seems reasonable, except that 'twin' can be superficial and I suspect that separate objects are "deeply separate", so at least a deep_twin should be used.
Following your example, and dusting off some old memories, there used to be a kind of global once (vs per process) that, with a lot of prudence and a little protection, should be shareable across processors.
Has that concept disappeared in the scoop era?

R
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

Anders Persson

unread,
Feb 25, 2020, 11:43:37 AM2/25/20
to Eiffel Users
Hi

Or maybe the possibility to transfer an object from one region to another.

Vänligen

Anders Persson
+46 763 17 23 25





--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

Larry Rix

unread,
Feb 25, 2020, 11:56:52 AM2/25/20
to Eiffel Users
Yes! A wholesale transfer of the object from one Region-Processor to another is in this case what I am after. Which I think means the compiler has to statically prove that all references to the object in the sender or source Region-Processor are nonexistent or safely disconnected, yes?

SVHarvey (Optus)

unread,
Mar 4, 2020, 3:15:43 AM3/4/20
to eiffel...@googlegroups.com
As far as I am aware, SCOOP as currently implemented using threads is in its infancy.
I believe that the SCOOP architecture is intended to cater for different “Process Regions” in the following variants … Region B is a process on a separate ...
  • thread to that of Region B, but on the same CPU - which therefore has access to the same memory at the operating system level.
  • CPU on the same machine - which may or may not have access to the same  memory at the operating system level.
  • machine in the same cluster - which may or may not have access to the same memory at the cluster level.
  • machine in the same network - which may or may not have access to the same memory at the network level.
  • machine in a different network - which probably dies not have access to the same memory at all.

I believe that ...
  • Only in the first two of these varieties would be definitely amenable to some form of non-serialised-cloning, because some form of operating-system-level memory copy could be invoked.
  • The third and forth may be amenable to non-serialised-cloning in highly advanced and sophisticated server & network setups, because some form of memory-server-level memory copy could be invoked.
  • The last would force the use of serialised-cloning.
However, implementing this differentiation would add significant intricacy and complexity to the SCOOP compiler and SCOOP runtimes as well as probably add to language complexity.

Simon

Gachoud Philippe

unread,
Mar 4, 2020, 4:01:29 AM3/4/20
to Eiffel Users
I would say that declaring a separate object forces to declare its access as `separate foo as l_foo do l_foo.do_some_stuff end` or in an enclosed routine forces the compiler to generate some code that gives exclusive access to it as it is a shared object in memory so that concurrent access is denied.


On Tuesday, February 25, 2020 at 1:56:52 PM UTC-3, Larry Rix wrote:
Yes! A wholesale transfer of the object from one Region-Processor to another is in this case what I am after. Which I think means the compiler has to statically prove that all references to the object in the sender or source Region-Processor are nonexistent or safely disconnected, yes?

On Tue, Feb 25, 2020, 11:43 AM Anders Persson <and...@bsharp.se> wrote:
Hi

Or maybe the possibility to transfer an object from one region to another.

Vänligen

Anders Persson
+46 763 17 23 25





On Tue, 25 Feb 2020 at 16:57, Larry Rix <lar...@moonshotsoftware.com> wrote:
This also makes me wonder why one could not just

1. Receive a reference from another SCOOP Region
2. Create a twin of it (as long as it can be twinned)
3. Give the new Recipient SCOOP Region-Process control over the newly minted (twinned) reference.

To put it more succinctly—within a call of 'my_object (a_arg: separate ANY)' we find code like:

'a_local_thing := a_arg.twin_from_separate'

So—you're not just creating a 'twin' of a thing, you're presuming the thing is in a separate Region with its own Processor and the goal is to make a twin (copy) of the other Regions object and give control of the twinned object to the new Target Region and its Processor.

Yes?

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages