[PATCH 3/5] jscript: Implement script persistence.

Gabriel Ivăncescu gabrielopcode at gmail.com
Thu Nov 7 06:19:59 CST 2019


On 11/6/19 6:57 PM, Jacek Caban wrote:
> On 11/6/19 5:50 PM, Jacek Caban wrote:
>> Hi Gabriel,
>>
>> On 11/6/19 4:28 PM, Gabriel Ivăncescu wrote:
>>> --- a/dlls/jscript/jscript.c
>>> +++ b/dlls/jscript/jscript.c
>>> @@ -62,6 +62,8 @@ typedef struct {
>>>         bytecode_t *queue_head;
>>>       bytecode_t *queue_tail;
>>> +    bytecode_t *persistent_head;
>>> +    bytecode_t *persistent_tail;
>>
>>
>> I think it would be cleaner to use struct list from wine/list.h instead. 
> 
> 
> I replied too soon. It would be generally preferable, more importantly, 
> it's the same question as I had for vbscript: why do we need a separated 
> list? Can we just store a flag?
> 
> 
> Thanks,
> 
> Jacek
> 

We can use a flag, but then we have to also use a flag for queued code, 
just like vbscript (where it has both pending_exec and is_persistent). 
Meaning we have to revamp the current implementation with queue list.

That's because without a pending_exec flag, we'll lose the code list 
when the queue gets cleared -- and thus, access to the persistent code 
list, too. Unless, of course, we store two lists but that's what the 
patch had already.

The reason is that persistent and non-persistent code can be mixed in 
ordering, for example (P = persistent, N = non-persistent):

P->P->N->P->N

So the queue now looks like the above. Then the script is started and 
they get executed.

When it is uninitialized, and then re-initialized, the queue is now:

P->P->P

because the persistent code has to be re-executed. Adding more code 
before starting the script will add to the end, of course.


But currently, we keep a queue of pending code *only*. So, if the script 
gets started, the queue gets cleared. That means we lose access to the 
persistent code list without a second list, and thus can't re-queue it 
back when it is uninitialized.


So, should I proceed with two flags like in vbscript and a single list?

Thanks,
Gabriel



More information about the wine-devel mailing list