SimpleScript Part Six: Threading Technicalities

re: SimpleScript Part Six: Threading Technicalities

Nicholas Allen — Tue, 27 Apr 2004 05:59:00 GMT

I'm trying to plan out how you're going to support the thread model for InterruptScriptThread and Clone. Let me know if you're looking at a different direction.

The basic problem is that InterruptScriptThread and Clone can be called from any thread at any time on an initialized engine. These unruly calls look like the hardest part of the threading model to provide.

For InterruptScriptThread it doesn't seem that bad, maybe. Calling InterruptScriptThread trips a latch and then returns successfully. Scripts periodically pause and run a callback to the engine after chunks of work. One of the things this callback does is check the latch, and if it was tripped the script is killed. And, stopping a script (interrupt or normal termination) resets the latch.

Does InterruptScriptThread guarantee that the script stops before the function returns or just at some hopefully near point in the future? If it has to stop right away, I guess after tripping the latch, InterruptScriptThread could wait for a signal from the callback that the script has stopped before returning.

Clone is a little harder because it has to have the return result right away. I'm going to guess it uses the second approach where Clone sleeps until the next callback and then copies the state. This looks safe because from outside the engine, it's impossible to distinguish that delay from the script already being at the callback and Clone just taking a while. The assumption here is that there's no practical way to Clone while a script is actually executing. That is just madness, right, since the script could mutate some of the engine state while you're copying?

re: SimpleScript Part Six: Threading Technicalities

Nicholas Allen — Tue, 27 Apr 2004 06:11:00 GMT

> boy, do I ever not want to implement single-writer-multi-reader mutexes

Is that really so bad? A basic one is just a semaphore if we cheat and only allow a bounded number of simultaneous readers, right? And a writer preference read-write lock is just a mutex+semaphore. Or did you mean a robust, extremely scalable, high performance implementation in which case it probably would suck to do given the win32 sync primitives.

I'd be surprised if they didn't turn out to be useful in at least a couple more places.

re: SimpleScript Part Six: Threading Technicalities

Eric Lippert — Tue, 27 Apr 2004 06:33:00 GMT

Re: InterruptScriptThread

You're on the right track. I'll cover all this stuff in a whole lot more detail when we get there, but basically ISC sets a threadsafe "halt soon" flag, VBScript and JScript check the flag at the beginning of every statement.

re: SimpleScript Part Six: Threading Technicalities

Eric Lippert — Tue, 27 Apr 2004 06:35:00 GMT

Re: Clone -- you need to be able to clone a running engine. The trick there will be the fact that once the engine has compiled state, that state is read-only, and hence can be easily shared amongst engines. I'll have to build a mutex into the code block list similar to the named item list.

re: SimpleScript Part Six: Threading Technicalities

Eric Lippert — Tue, 27 Apr 2004 06:37:00 GMT

Re: SWMR mutexes -- yeah, it's not that hard, but I'm doing this in my spare time, and the straightforward critsec code is easy.

re: SimpleScript Part Six: Threading Technicalities

Mike Dimmick — Tue, 27 Apr 2004 10:29:00 GMT

I thought that the 'Both' threading model meant that if created from a STA-model thread (I can't remember the correct terminology - it called CoInitialize, OleInitialize or CoInitializeEx with the COINIT_APARTMENTTHREADED flag) the object ends up in the STA, whereas if created from an MTA-model thread (called CoInitializeEx with COINIT_MULTITHREADED) it ends up in the MTA.

re: SimpleScript Part Six: Threading Technicalities

Eric Lippert — Tue, 27 Apr 2004 14:34:00 GMT

Correct -- like I said, I was simplifying my description of the model. The important point is that both-threaded objects do not automatically aggregate the free threaded marshaler.

re: SimpleScript Part Six: Threading Technicalities

Nicholas Allen — Tue, 27 Apr 2004 17:14:00 GMT

Does "beginning of every statement" mean once per language statement? So if I call in JScript:

a.sort();

and a happens to have 100M elements I have to end task the engine? How about if I do:

a.sort(function f(x,y){return x-y;});

Does each invocation of f count as a statement so that interrupt works as expected?

re: SimpleScript Part Six: Threading Technicalities

Nicholas Allen — Tue, 27 Apr 2004 17:26:00 GMT

I think I may have the wrong impression of what Clone does in a running engine. Does it:

a) Copy the engine state such as code and items but not the executing scripts. The new engine has no activity initially after Clone.

b) Copy the engine state and the executing scripts. The new engine is off and running at the exact same instruction point as before the Clone.

I had in my mind that it was b) which doesn't seem to support the implementation you describe. Specifically, if I'm doing an eval and want a b) type Clone I need to bring along the compiled eval block so the state isn't really read-only. If I'm doing an eval and want a a) type Clone, well it's no problem since the eval code is an anonymous block which doesn't need to be copied. Closures would probably have the same problem.

Or is a b) type Clone really possible by being careful enough about when eval can happen?

re: SimpleScript Part Six: Threading Technicalities

Eric Lippert — Tue, 27 Apr 2004 17:26:00 GMT

By "beginning of every statement" I mean just that. Before we start a statement, we check to see if the halt flag is set. In your second example, since "return" is a statement, we'll check once every comparison.

In your first example, you're out of luck. You call a method that takes half an hour to come back, you don't get to halt the script for half an hour.

Of course, an array would never have 100 million entries in JScript -- that would take up more memory than the entire process space, and forget sorting -- _garbage collection_ would take forever.

If you have a hundred million entries to sort, I recommend using a rather more buff tool, like SQL Server.

re: SimpleScript Part Six: Threading Technicalities

Eric Lippert — Tue, 27 Apr 2004 17:30:00 GMT

Re: what does clone do:

Clone does (a). Clone is motivated by Active Server Pages. You have an engine compiled and running which, when executed, serves up foo.asp. A second request for foo.asp comes in on another thread while the first one is still running. Without clone you have two choices:

1) wait for the first one to finish, uninitialize the engine, reinitialize it on the new thread -- thereby serializing access to that page.

2) create a new engine on the new thread and recompile the state, which is potentially expensive.

Clone mitigates both these problems. A cloned engine doesn't have the cost of compiling the same program all over again and it can run at the same time as the clonee on another thread.

Read http://blogs.msdn.com/ericlippert/archive/2003/09/18/53046.aspx for more details.

re: SimpleScript Part Six: Threading Technicalities

Nicholas Allen — Tue, 27 Apr 2004 18:07:00 GMT

True, 100M is probably out of reach for 32 bit code. But even 100K is going to take a very long time to complete. If I'm browsing the web and some malicious page decides to chew my CPU, I don't get to choose the tool.

As for GC taking forever, I'm guessing that's because you've got a stop the world, mark and sweep collector in mind. Which is an adequate tool for the job but similarly not industrial strength.

re: Clone. Thanks, that removes a lot of the hairy problems I had dreamed up.

re: SimpleScript Part Six: Threading Technicalities

Eric Lippert — Tue, 27 Apr 2004 18:12:00 GMT

Re: DOS: Correct -- though we have some defences in place against simple denial-of-service attacks, it is possible for a hostile web page to chew up a whole lot of CPU and memory, and make IE look hung.

Re: GC: Correct, JScript uses a stop-the-world, mark-n-sweep collector and runs it every time 256 variants, 4096 array slots or 64KB of strings are allocated, so allocating large chunks of memory becomes an order n-squared operation as n becomes large. JScript was designed for simple scripts on simple pages, not for implementing databases.

See http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx for details.

I haven't decided what kind of GC to put into SimpleScript yet.

re: SimpleScript Part Six: Threading Technicalities

Eric Lippert — Tue, 27 Apr 2004 22:05:00 GMT

> Does InterruptScriptThread guarantee that the script stops before the function returns or just at some hopefully near point in the future?

InterruptScriptThread guarantees nothing as far as timing goes. For example, what if IST is called while the engine is executing the LAST statement? Then we never check the halt flag and never return SCRIPT_E_ABORTED back to the host. We do however put the engine into "halted mode".

We'll get into all this in way more detail later, I promise, so hold your horses for now. There are all kinds of questions that we'll have to consider: what happens when you attempt to halt an already halted engine? What if you attempt to call ParseScriptText on a halted engine? How do you reset an engine out of halted mode? Etc, etc, etc.

Links about COM threading models

The Old New Thing — Tue, 11 May 2004 17:00:00 GMT

Raymond makes other people discuss stuff so he doesn't have to.

Links about COM Interop and threading

Hirlpoo — Tue, 11 May 2004 18:14:00 GMT

Links about COM Interop and threading

Hirlpoo — Tue, 11 May 2004 18:39:00 GMT

New and Notable 55

Sam Gentile's Blog — Wed, 12 May 2004 15:30:00 GMT

New and Notable 55

Sam Gentile's Blog — Wed, 12 May 2004 19:17:00 GMT