sorry, just trying to clarify a few points...
On 8/3/2011 9:57 AM, BGB wrote:
in my own language, there is the "async" modifier which can
(theoretically) be used for a lot of this:
"async function foo(x, y) { ... }"
where calls to foo implicitly create their own thread.
"async bar(x, 3);"
would create a new thread for the call (IIRC, the initial version of
the language had also allowed the "bar!(x, 3);" syntax as well).
"async { ... }"
would execute the code block in a new thread.
granted, an "thread" modifier could make sense here instead?... (maybe
aliased to "async" or maybe replacing "async").
note, care should be taken not to confuse my "async" modifier with the
C# "async" modifier, as they essentially do different things (much like
my "delegate" keyword and the C# "delegate" keyword do different things,
...).
still uncertain if a thread modifier would make more sense (in general,
"thread" does make more sense, say, for TLS variables, as "async var
mytls;" would look silly...).
things are allowed to be a bit more fluid here, since there is not
exactly a whole lot of code around depending on mostly
not-yet-implemented features.
sadly, the "async" modifier was used in the first incarnation of
BGBScript (2004-2006), but was never fully reimplemented when the
language was later re-implemented (it has been on a long-term to-do
list, but there were many more pressing features to get implemented,
and alternative if albeit less convenient mechanisms exist...).
the issue is granted, not so much whether one can type, say:
for(i=0; i<100; i++)
fun(i) { async printf("%d\n", i); } (i);
but whether or not it will "own" their computer in the process...
(note: ugly closure hack needed to give each thread a proper unique
value for 'i', again probably another weak point of the existing model).
except that, as written, the above would not "own" ones' computer, due
to a few details:
the threads are too short-lived, so a momentary 100% CPU spike on all
cores would not likely be noticed too badly;
using a "soft" threading model, likely only a single worker OS thread
would spawn which would service all of the threads, very possibly
sequentially (the threads are likely too short-lived to trigger
additional workers to spawn);
with soft threading, the memory use is likely to be fairly trivial
(nowhere near crash-risk levels);
a larger number of OS threads would be needed to threaten the program
(500-700 would likely crash a 32-bit the process on Windows, but the OS
would probably survive this, 200-400 would likely crash a 32-bit Linux
process, in both cases likely due to running out of address-space).
so, I guess it can be more taken "in principle" that naively spawning a
large number of OS threads could crash stuff...
slight (possible/eventual) syntax sugar could be something like:
for(i=0; i<100; i++)
async(i) printf("%d\n", i);
with the semantics that "i" is captured at the point the statement is
seen, essentially turning the operation into a lambda-block and an async
call operation. also this would save 1 code block vs the prior form
(both async and closures use blocks, using both thus requires 2 blocks,
but a combined form would only need a single block).
note that otherwise, the variable will be captured, rather than its
value, hence the "printf" call would see whatever was the last value in
the variable. it is then necessary to "capture" its value at the point
of execution so that the explicit value at that moment is captured.
note, the effective opposite of "async" (or "thread", if added) would
be "synchronized", as in:
"synchronized { ... }" which would use a mutex (or some other means)
to synchronize execution within a given block.
it can also be (theoretically) applied to methods and classes (sadly
also not presently implemented).
now whether any of this could make threading easier to use... I really
have little idea...
my good old friend implementation holes.
this is because I can sometimes spec out more features than I have
implemented, or older features can "fall off a ledge" somewhere (say,
when doing a mostly ground-up reimplementation of ones' VM).
maybe there is some fundamentally better way to approach
multi-threaded code?...
still a mystery...
maybe in a more ideal world, maybe everything could just be converted to
CPS and executed wherever a worker was available (essentially blurring
the line between single and multithreaded code). however, how to best
express and work with concurrent code is still an issue though.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
