Re: Evaluating definitions from another thread

[Panicz Maciej Godek <godek.maciek@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

sob., 11 maj 2024 o 17:44 Per Bothner <per@bothner.com> napisał(a):

> If you allow the user to evaluate arbitrary expressions, that should be
> done in a separate
> context (environment) than GRASP itself. The user context should not
> inherit everything from
> the GRASP context; only deliberately exported bindings, mostly read-only.
> And the user context
> should not be able to add or modify arbitrary bindings in the GRASP
> context; only bindings
> that the GRASP engine deliberately amkes available to the eval context.
>

I agree that, at some point, this will need to be addressed - in
particular, when people start sharing
extensions that they write, I'll need to create a model for managing access
to particular parts
of the system.

However, at this moment coming up with a compelling way of creating
extensions is much more
important.



> This is security 101. Of course if you just want to make some someware for
> yourself to
> learn or play around with, do what you like. But if you want to write
> software for others
> to use, you need to consider security issues.
>
> If you want each evaluation to be performed on a separate thread, then you
> need to consider
> how things are synchronized: How updates in the eval thread cause changes
> in the GRASP engine.
> It is possible that using parameters will "do the right thing" - but I
> wouldn't count on it.
>
>
Today I developed the following subclass of ThreadLocation:

https://github.com/panicz/grasp/compare/main...shared-parameters

The idea is that the values stored in the thread locations are themselves
SharedLocations.
According to my test, they behave as expected:

(define x (make-shared-parameter 'x 0))

(parameterize ((x 1))
  (future
   (begin
     (sleep 1)
     (display "changing x from ")
     (display (x))
     (set! (x) 2)
     (display " to ")
     (display (x))
     (newline)))
  (display "inner value of x: ")
  (display (x))
  (newline)
  (sleep 2)
  (display "inner value of x after 2 seconds: ")
  (display (x))
  (newline)
  )

(display "outer value of x: ")
(display (x))
(newline)

 The output produced by running the above program is

inner value of x: 1
changing x from 1 to 2
inner value of x after 2 seconds: 2
outer value of x: 0


whereas if - instead of using "shared parameters", I use the regular
parameters, I get

inner value of x: 1
changing x from 1 to 2
inner value of x after 2 seconds: 1
outer value of x: 0

I didn't quite understand why the constructor of SharedLocation requires a
timestamp, and I passed it (java.lang.System:currentTimeMillis).
Is that OK?