Evaluating definitions from another thread

Evaluating definitions from another thread

[Panicz Maciej Godek]

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

Hi,

I've noticed that when I call

(future (eval '(define x 5)))

then the variable x remains unbound after the execution
- even though when I invoke (eval '(define x 5)), x gets bound to 5 as
expected.

Is there a way to have evaluated definitions introduce new bindings
regardless of the thread they're being evaluated from?

Re: Evaluating definitions from another thread

[Per Bothner]

On 5/10/24 1:15 PM, Panicz Maciej Godek via Kawa wrote:
> Hi,
> 
> I've noticed that when I call
> 
> (future (eval '(define x 5)))
> 
> then the variable x remains unbound after the execution
> - even though when I invoke (eval '(define x 5)), x gets bound to 5 as
> expected.

This might work:

(define x #f)
(future (eval '(set! x 5)))
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Evaluating definitions from another thread

[Panicz Maciej Godek]

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

pt., 10 maj 2024 o 22:19 Per Bothner <per@bothner.com> napisał(a):

>
>
> On 5/10/24 1:15 PM, Panicz Maciej Godek via Kawa wrote:
> > Hi,
> >
> > I've noticed that when I call
> >
> > (future (eval '(define x 5)))
> >
> > then the variable x remains unbound after the execution
> > - even though when I invoke (eval '(define x 5)), x gets bound to 5 as
> > expected.
>
> This might work:
>
> (define x #f)
> (future (eval '(set! x 5)))
>


Thanks, it does the trick for simple cases.
I currently scan for the appearance of "define", then extract for the
symbol and build a binding, and then evaluate

`(set! ,symbol
   (let ()
    ,expression
    ,symbol))

but if I wanted to handle a more general case (such as a begin form
containing some definitions), I'd probably need to implement something
closer to a full evaluator,
which makes me wonder whether the above behavior (with variables not being
bound from other threads) is actually desired?

Re: Evaluating definitions from another thread

[Per Bothner]

On 5/10/24 2:03 PM, Panicz Maciej Godek wrote:
> which makes me wonder whether the above behavior (with variables not being bound from other threads) is actually desired?

Yes. If a child thread needs to define new variables in the parent thread,
you're almost certainly doing something wrong.

More generally: Most of the time people use eval, they shouldn't.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Evaluating definitions from another thread

[Panicz Maciej Godek]

[-- 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?

Re: Evaluating definitions from another thread

[Per Bothner]

On 5/12/24 2:08 PM, Panicz Maciej Godek wrote:
> I didn't quite understand why the constructor of SharedLocation requires a timestamp, and I passed it (java.lang.System:currentTimeMillis).
> Is that OK?

No. It is not an actual timestamp - more of a version number.
(The fact that 'timestamp' is an int and currentTimeMillis is a long should tell you
that currentTimeMillis() is not a suitable value for 'timestamp'.)

The timestamp is used to control whether a binding is shared.
It's been so long since I wrote this code, I don't remember precisely how it works.
You can look at the code.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/