long running threads, service vm etc.

> Norbert,
>
> This sounds very similar to the work that Nick did with futures[1] and I see that I've neglected to include that work in the standard configuration...
>
> You wouldn't follow the future pattern, but you follow the scheme of launching a thread to execute a block on a gem dedicated to run that task (plus others). you could arrange for a shared persistent variable (instance variable in the task object?) for controlling the start/stop of the task ...
>
> Dale
>
> [1] http://forum.world.st/threads-within-a-request-td2335295.html#a2401872
>
> ----- Original Message -----
> | From: "Norbert Hartl"<[hidden email]>
> | To: "GemStone Seaside beta discussion"<[hidden email]>
> | Sent: Friday, November 25, 2011 1:50:51 AM
> | Subject: [GS/SS Beta] long running threads, service vm etc.
> |
> | The question Marten was asking started to make me think how I would
> | port my current project from pharo to GemStone. The project has a
> | couple of suites that fetch things from the net via http. Every
> | suite has its own thread and configuration to work alone collecting
> | data. The configuration and the control of a single suite is done
> | via the web interface.
> |
> | I took a look at service vm but I think my use case is completely
> | different. In my case it isn't sufficient to snap off taks and let
> | them be completed by a different gem. I need multiple long running
> | threads. The configuration is not that big problem because I can
> | commit from the web interface and the executing gem can just read
> | it. But I would need to have direct control of the lifecycle of a
> | thread. On the web interface there is a start/stop button to start
> | or stop the thread that collects data. How would you handle this
> | case where direct control is needed. Would this be something for gem
> | to gem announcements? Or is there something better? I would like to
> | avoid having a rest handler in the executing gem that I can trigger
> | via http from the web interface ;)
> |
> | thanks in advance,
> |
> | Norbert

> Paul,
>
> Is there a glassdb issue on my checking the scripts? If not let's add one ... my plate overflowed a while ago and I may have left some scraps on the floor, where the doggies could get them:) Ah ... the dog ate my backlog:)
>
> Dale
>
> ----- Original Message -----
> | From: "Paul DeBruicker"<[hidden email]>
> | To: "GemStone Seaside beta discussion"<[hidden email]>
> | Sent: Tuesday, November 29, 2011 10:43:38 AM
> | Subject: Re: [GS/SS Beta] long running threads, service vm etc.
> |
> | In the Tropo port to gemstone I set a Zinc server to run in its own
> | gem
> | and independently respond to incoming SMS messages and phone calls.
> | Maybe there's something there for you.  It was started/stopped
> | through a
> | bash script which was called from inside Gemtools.  I know Dale added
> | it
> | to his plate to clean up my scripts but I haven't tracked the
> | progress
> | in some time.
> |
> |
> | On 11-11-29 09:47 AM, Dale Henrichs wrote:
> |>  Norbert,
> |>
> |>  This sounds very similar to the work that Nick did with futures[1]
> |>  and I see that I've neglected to include that work in the standard
> |>  configuration...
> |>
> |>  You wouldn't follow the future pattern, but you follow the scheme
> |>  of launching a thread to execute a block on a gem dedicated to run
> |>  that task (plus others). you could arrange for a shared persistent
> |>  variable (instance variable in the task object?) for controlling
> |>  the start/stop of the task ...
> |>
> |>  Dale
> |>
> |>  [1]
> |>  http://forum.world.st/threads-within-a-request-td2335295.html#a2401872
> |>
> |>  ----- Original Message -----
> |>  | From: "Norbert Hartl"<[hidden email]>
> |>  | To: "GemStone Seaside beta discussion"<[hidden email]>
> |>  | Sent: Friday, November 25, 2011 1:50:51 AM
> |>  | Subject: [GS/SS Beta] long running threads, service vm etc.
> |>  |
> |>  | The question Marten was asking started to make me think how I
> |>  | would
> |>  | port my current project from pharo to GemStone. The project has a
> |>  | couple of suites that fetch things from the net via http. Every
> |>  | suite has its own thread and configuration to work alone
> |>  | collecting
> |>  | data. The configuration and the control of a single suite is done
> |>  | via the web interface.
> |>  |
> |>  | I took a look at service vm but I think my use case is completely
> |>  | different. In my case it isn't sufficient to snap off taks and
> |>  | let
> |>  | them be completed by a different gem. I need multiple long
> |>  | running
> |>  | threads. The configuration is not that big problem because I can
> |>  | commit from the web interface and the executing gem can just read
> |>  | it. But I would need to have direct control of the lifecycle of a
> |>  | thread. On the web interface there is a start/stop button to
> |>  | start
> |>  | or stop the thread that collects data. How would you handle this
> |>  | case where direct control is needed. Would this be something for
> |>  | gem
> |>  | to gem announcements? Or is there something better? I would like
> |>  | to
> |>  | avoid having a rest handler in the executing gem that I can
> |>  | trigger
> |>  | via http from the web interface ;)
> |>  |
> |>  | thanks in advance,
> |>  |
> |>  | Norbert
> |
> |