On 8/3/2011 5:13 PM, David Barbour wrote:
On Wed, Aug 3, 2011 at 1:04 PM, Igor Stasenko <siguc...@gmail.com
<mailto:siguc...@gmail.com>> wrote:
it is pointless to spawn more than hardware can do, because these
threads will just wait own turn to claim one of free cores
and meanwhile just consume resources
I agree, with exceptions:
* blocking FFI calls
* FFI that uses thread local storage
We can handle common synchronous IO cases (files, sockets) more
explicitly in the implementation (futexes, etc.), but it is difficult
to cover what an FFI might do.
yeah.
this is why one can spawn more workers if there is a delay.
say, a thread goes and makes a blocking IO call via the FFI, ideally
this shouldn't lock up the whole VM as a result...
currently, I have the thread-spawn delay set at 100ms.
the work-dispatcher will just assume that if a work request has been
there longer than 100ms, then more workers are probably needed.
Some FFI libs - OpenGL, for example - use thread local storage for
implicit context between operations. Thus, developers must guarantee
that a given soft thread remains bound to a specific OS thread.
GHC Haskell provides special constructors (forkOS, forkOnIO) to
support these issues.
interesting, I hadn't thought of this particular issue.
as is, any calls directly from C code (function calls, evals, ...) will
run directly in the calling thread, and there is at present no implicit
threading in this case.
but, if scripts go and create threads, and then try to use something
like OpenGL from these threads, then very possibly things will blow up.
the most direct option for this would be to support some mechanism
whereby the code is executed directly on the calling thread, rather than
using soft-threading (which involves a different execution mechanism,
basically where a call is made to "execute stuff" giving it a VM context
and a timeout, generally with this call returning when either the thread
terminates or the timeout expires, ...).
an dirty hack would be to just tack another modifier on the block, like
"final async { ... }" or something... (yes, granted, modifier soup is a
little ugly sometimes, but is an easy way to tack more semantics onto
things...).
IMO, high-granularity parallelism is road to nowhere.
Don't confuse threading with parallelism! Consider what we can do with
SIMD, DSP, and FPGA, for example.
or even a GPU...
BGB Wrote:
another idle thought is if a language that already has dynamic
scope actually needs TLS as well. the issue is that having both
could be needlessly redundant.
If you have dynamic scope, you do not need TLS.
probably, but some people could potentially get annoyed or complain
about having to re-declare their thread-local dynamic variables when
spawning a thread.
like:
async {
dynamic var foo=null;
dynamic var bar=null;
dynamic var baz=null;
...
}
the above being mostly to create new/fresh thread-local dynamic vars
(otherwise they would be shared with the parent).
granted... one can just use them as dynamic vars as usual and they
should be fine, rather than treating them like global state.
note: BS doesn't have "(let)" or similar, so re-declaring the variables
(rather than assigning them) will serve a similar purpose to let in this
case.
oh well, went and added a basic job-queue mechanism (in C land):
BGBGC_API BGBGC_Job *thAddJob(void *(*fcn)(void *data), void *data);
BGBGC_API BGBGC_Job *thAddJobDelay(void *(*fcn)(void *data), void *data,
int ms);
BGBGC_API void thFreeJob(BGBGC_Job *job);
BGBGC_API void *thJobGetData(BGBGC_Job *job);
BGBGC_API void *thJobGetValue(BGBGC_Job *job);
BGBGC_API int thJobGetDone(BGBGC_Job *job);
should be fairly straightforward.
the jobs are basically just function callbacks executed in the context
of worker threads. they are not "threads" per-se, but a callback can
re-add a job before returning, so can sort of act like a thread.
the AddJobDelay was basically just a last-minute addition to support an
issue which comes up sometimes: wanting something to happen after a
certain delay. ms is basically a count of (about) how long it is until
it would be executed (it is likely to not be all that "exact", but
probably close enough for things like animation/...).
by default, the Job structure is not freed automatically (so that one
can fetch the return value), but there is a special return value to
cause it to be freed immediately.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
