Re: embeddable threaded interpreted language

David Randolph Conrad <davidc@iij.ad.jp> wrote:
>I may not be using the proper terminology (I'm a network weenie, not a
>compiler weenie), if so, my apologies. I'm looking for a small embeddable
>interpreted language for an application I am writing. The catch is that
>my application has better things to do than sit and wait around for the
>language interpreter to finish. Specifically, I would like a language
>where I can have multiple "threads" do:
>
> rc = interp( state, code, time_slice )
>
>and the interpreter will execute 'code' for at most 'time_slice' steps
>(seconds, whatever). All the code for embeddable languages I've seen to
>this point have been "run till the end of the code" types like icon, tcl,
>perlv5, etc. My first thought was to write a p-code translator and
>interpreter, but I'm hoping I don't have to reinvent the wheel.
>




I'm not quite sure what you mean by "run till the end of the code" but:


Icon has coroutine expressions. They don't do quite what you want,
but perhaps they can be hacked to get close. The code that supports
coroutines must have all of the support for a separate stack and
saving/restoring of context. But coroutines _explicitly_ return
control back to the calling routine. But perhaps a signal catcher can
be added to the support code to force an early return.




Python has a "thread" package - but it's only supported on SGI or
SunOS - I assume it uses the underlying OS lightweight threads
package. But, maybe it can be rebuilt with "pthreads" or some
portable implementation. But it still doesn't support explicit
timeslicing of threads.




You *ought* to be able to do this in a scheme that supports call/cc.




There are multitasking versions of FORTH that will do what you want.




Sorry, I don't have time to research exactly how much hacking is
required for any of these solutions ( and your description was not
specific enough on some of YOUR requirements - like portability: I
assume that is a requirement or you could just sleep/wake unix
"heavy-weight" processes. ) but they may give you a lead.




- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics




[ Followups redirected to comp.lang.misc - this isn't really
    a compiler question, is it? ]


-------------- python/src/thread.doc ---------------


void init_thread(void);
Initialise the package. Can be called explicitly, but will
be called automatically when the first start_new_thread or
allocate_lock is called.
int start_new_thread(void (*func)(void *), void *arg);
Start a new thread. In the new thread, func(arg) will be
called. The thread exits when func returns.
Returns 1 if a thread could successfully be started, 0
otherwise.
void exit_thread(void);
Exit current thread. Equivalent to returning from the
above-mentioned func.
Does not return.


typedef ... type_lock;
Opaque type for a lock. This is a pointer type.
type_lock allocate_lock(void);
Allocate a lock structure and return an opaque pointer to it.
Return 0 if not successful.
void free_lock(type_lock lock);
Deallocate a lock.
int acquire_lock(type_lock lock, int waitflag);
Try to acquire a lock. Return 1 if the lock could
succesfully be acquired, 0 otherwise.
If waitflag is set (i.e. != 0), wait until the lock
can be acquired.
void release_lock(type_lock lock);
Release the lock.


void exit_prog(int status);
Exit the application with exit status "status".
Does not return.


Do we need condition variables?
What sort of support is needed for interrupts?


Because on the Sun, threads are implemented in a single Unix process,
it is usually not a good idea to call blocking system calls. When
linked against the -lnbio library (non blocking I/O) you get versions
of some of the blocking system calls that won't block the whole
process.


It is not safe to call exit(), since the behaviour is different on
SGI and Sun. On Sun, it will kill the whole application, whereas on
SGI it will only kill the calling thread.


It is safe to call exit_thread() from the main thread, but the
behaviour on Suns and SGI's will be different. On the Sun, the
process will continue to run, but on the SGI, the parent process's
wait will return. The other threads will continue to run, however.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.