Hi Jimmy,
To the question whether non-SCOOP systems should use `separate` blocks,
the answer is no. In non-SCOOP systems, the keyword `separate` is just
ignored. So creating an object of type `separate T` is like creating
an object of type `T`. In non-SCOOP system, it's as if we have only
one region, and all objects are created in this region, regardless of
the `separate` keyword.
To the question whether it will affect non-SCOOP systems, the answer
is probably. If the system is designed to work with different SCOOP
regions concurrently, some code may never be executed. For example
when creating an object declared of a separate type, in SCOOP mode
this object will live its own life in its separate processor, while
the instructions following this creation will be executed. In non-
SCOOP mode, the instructions following this creation will be executed
only after creation procedure returns, which may never happen (for
example if this object is listening to a socket). But you can tailor
your code to work in both modes using `{PLATFORM}.is_scoop_capable`.
You can find an example here:
https://github.com/gobo-eiffel/gobo/blob/312f94ce4f472ccd63aca497cfc31de5b246b447/library/langserver/src/client_server/ls_message_manager.e#L645
In this example, in non-SCOOP mode, messages are not handled here,
avoiding endless execution.
Is moving to SCOOP worth the effort? It depends on the benefit you
will gain from having a concurrent system. I have a personal private
project which is similar in some way to yours. The difference is that I
wrote it from scratch with SCOOP, instead of having it single-threaded
and then modifying it to make it SCOOP aware. My system is a home
automation system. For example one thing that it does is to show a
map of my house, and when a light is turned on in some room, then
this room is displayed in yellow on the map. When I click on a
room on the map, the light will turn on if it was off, or vice-versa.
So it works more or less like your views, with events that trigger
some actions in other regions. There is the UI SCOOP region (the map
displayed on the screen, using EiffelVision2), a region containing
the model objects (light objects, room objects, etc.), a region to
listen to sockets to get physical events (i.e. a light being turned
on) and another region to send command to the physical world (i.e
turn off the light). When an event is received on the socket, the
model object is notified (asynchronous call) and updated. When the
model object is updated, the view is notified (asynchronous call)
and updated. When the user asks for an action, the UI receives this
request, and notify another region (asynchronous call) to send the
command to the physical world. This system has not been designed to
work in non-SCOOP mode. So I'm pretty sure it will hang somewhere
(probably in the code which listens to the socket) if executed in
non-SCOOP mode. But with some care, it could be made non-SCOOP
compatible.
Hope this helps.
--
Eric Bezault <
er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.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-users...@googlegroups.com <mailto:
eiffel-
>
users+un...@googlegroups.com>.
> To view this discussion visit
https://groups.google.com/d/msgid/eiffel-
> users/3fc8e4ed-44a9-4811-855e-5246873cd013n%
40googlegroups.com <https://
>
groups.google.com/d/msgid/eiffel-
> users/3fc8e4ed-44a9-4811-855e-5246873cd013n%
40googlegroups.com?
> utm_medium=email&utm_source=footer>.