On 11/7/19 1:19 PM, Gabriel Ivăncescu wrote:
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?
I can see your point. I'm not against separated lists, but I don't really like the way your patch makes it more complicated than it needs to be, eg. by adding additional fields to bytecode_t. I think that if you'd have the bytecode in only one list at a time (so pending persistent code would be only on pending list and it would be moved to persistent list when it's executed), it could be a bit cleaner. Of course then you'd need to store persistent flags to know which pending code should be removed when changing the state to SCRIPTSTATE_UNINITIALIZED.
In any case, to be able to easily remove entries from a queue, a double linked list would be nicer, so changing bytecode_t to use standard list first seems like a good idea.
Thanks,
Jacek