Threads and asyncs

Threads and asyncs

[Marius Vollmer]

Hi,

currently, when you mark a system-async, it is run at the next 'safe'
point.  This does not take the current thread into account and thus,
you can not have thread-specific system-asyncs.  One example where you
might want to have a thread-specific async is when you want to
interrupt the computation in a certain thread, the way you can now
interrupt the repl via C-c.

I would like to specify explicitely that marking a system-async will
run its thunk in the thread that did the marking.  That should not be
a large change since the next safe point will most likely occur before
the next thread switch.

Also, I'd like to add a function that marks a system-async for a
specified thread.  The async would run at the next safe point in that
thread.

The implementation can be changed from a global list of system-asyncs,
each with a mark, to a per-thread list of marked system-asyncs.
Marking a system-asnyc for a thread would add that system-async to the
thread's lists.  SCM_ASYNC_TICK would check whether the current
thread's list is non-empty.  Also, a thread would wake up when it is
blocked and run its asyncs anyway.

'sigaction' can be extended to allow marking of an async for a
specified thread.

With this change, an async would simply be a thunk.  We could just use
the thunk directly and deprecate the async abstraction.

OK?

(Non-system asyncs would not be affected.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

	> I would like to specify explicitely that marking a system-async will
	> run its thunk in the thread that did the marking.


Why can't that be layered?

In other words, start with thread-independent asyncs (which have the
virtue of simplicity and speed) and then build thread-specific on top
of that (at additional cost).

Is there no use for thread-independent system-asyncs?

There is a definate design tension trying to model stack-based,
kernel-driven execution in Scheme.

I've often considered layering call/cc for that reason -- making it
strictly optional, perhaps with a modest performance penalty,
implementing it via a transformation to continuation passing style.
One difficulty is primitives that call apply or eval: you can do away
with them or give them their own threads or mirror them in
tail-recursive scheme (somehow).

There are other alternatives, such as radical changes to the execution
model, so that C stacks aren't used by Scheme at all.  In my personal
Scheme design, this is the route I've (more or less) decided on.  When
worked out, and made to work cleanly with primitives written in
"classic C style" (i.e., freely calling eval or apply), I think it
winds up converging on more-or-less the same solution as making
call/cc work by transformation to CPS.

Anyway, where I to hack Guile, I'd look into building up the
abstractions to a point where eval is potentially a stackless graph
machine, instead of a hybrid stack/graph machine -- but preserving
optimizations such as SCM's copying-gc for environment frames.

-t


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Marius Vollmer]

Tom Lord <lord@regexps.com> writes:

> 	> I would like to specify explicitely that marking a system-async will
> 	> run its thunk in the thread that did the marking.
> 
> 
> Why can't that be layered?

Hmm, I don't see the need.

> In other words, start with thread-independent asyncs (which have the
> virtue of simplicity and speed) [...]

I don't think they are simpler or faster.

> Is there no use for thread-independent system-asyncs?

I can't think of any, right now.  The question is not whether to
execute a async in a thread or not, the question is only, in which
thread.  A thread-independent wouldn't care in what thread it is
executed so it is OK to run it in the thread that has marked it.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

	> I don't think they are simpler or faster.

Plausibly thread-independent asyncs are faster, at least by a few
instructions, since global data is less expensive to access than
thread-specific data.  Against that, I suppose, are locking issues.

My concern is not only how it works out in the current implementation,
as an incremental change -- but also how it works out as a candidate
feature of an implementation independent Scheme API.   While the
performance loss may be negligable in Guile, it might not be in other
plausible implementations.

There's always wiggle room.  Nobody has said that it's Guile's job to
solve the Scheme API problem.  You can (and have) just declare "that
doesn't matter for Guile's aims" and then there is no basis for
disagreement.


	> Is there no use for thread-independent system-asyncs?

	I can't think of any, right now.  

Any short computation that needs to be invoked asynchronously (say,
perhaps, driven by a timer) is a candidate.  One can imagine efficient
I/O working this way, for example; or simple animation of some sort in
a GUI.

Suppose we have a multi-CPU system and an application with roughly one
thread per CPU -- being able to schedule tasks that float to the next
available CPU seems obviously useful, to me.

-t


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Rob Browning]

Tom Lord <lord@regexps.com> writes:

> There are other alternatives, such as radical changes to the execution
> model, so that C stacks aren't used by Scheme at all.  In my personal
> Scheme design, this is the route I've (more or less) decided on.  When
> worked out, and made to work cleanly with primitives written in
> "classic C style" (i.e., freely calling eval or apply), I think it
> winds up converging on more-or-less the same solution as making
> call/cc work by transformation to CPS.

If I understand correctly, one of the reasons guile used the "one (C)
stack with copying" approach was so that call/cc could work properly
with a stack that included intermixed C and scheme function calls
without too much extra magic.  If that's a correct assesment, then how
do you deal with that problem in a stackless approach?

It was also my impression that the call/cc issue, along with an
aversion to having to explicitly deal with GC on the C side (which as
you've pointed out before might be dealt with via preprocessing,
etc.), were the two main things that would make switching to a
stackless approach somewhat controversial or difficult.  Are those the
only two big issues, or are there others?

(fairly interested in the topic ATM)

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

   From: Rob Browning <rlb@defaultvalue.org>

   > If I understand correctly, one of the reasons guile used the "one (C)
   > stack with copying" approach was so that call/cc could work properly
   > with a stack that included intermixed C and scheme function calls
   > without too much extra magic.  If that's a correct assesment, then how
   > do you deal with that problem in a stackless approach?


Well, blush....

I think I initially overvalued that feature.   I (nowadays) don't
think it should be central to _any_ implementation.

Instead, i'd make an implementation that is good as just a pure scheme
implementation, then add in that seductive integration with that C
stack via a foreign-function interface.  I think a good pure scheme is
not at all likely to use the C stack that way, especially for
procedures of central importance like `apply' and `eval'.

Most primitives, especially the core ones, would not rely on using the
C stack in the manner of SCM.

But since Guile is an extension language, one should _be able to_
write primitives that way (i.e. C-stack friendly), perhaps with a
modest performance trade-off, when necessary.  That would let people
add Guile to programs with minimal disruption.

In fact, the C-stack-friendly API could be made largely implementation
independent.

If Guile never budges on the stack issue, I would still be inclined to
see it as an implementation optimized for cases when the C stack is
used heavily.



   > It was also my impression that the call/cc issue, along with an
   > aversion to having to explicitly deal with GC on the C side (which as
   > you've pointed out before might be dealt with via preprocessing,
   > etc.), were the two main things that would make switching to a
   > stackless approach somewhat controversial or difficult.  Are those the
   > only two big issues, or are there others?

You've caught me talking from memory.   We'd need to sit down with a
wiki or whiteboard and map it out together.   I won't pretend to be
able to list all the issues off the top of my head.   I won't pretend
to have finished my own personal map of the various design spaces :-)

Do you have a good library of Scheme implementation papers?  Maybe
there should be a collaborative bibliography to bring together a bunch
of the good ideas floating around out there.

-t




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

       > If Guile never budges on the stack issue, I would still be
       > inclined to see it as an implementation optimized for cases
       > when the C stack is used heavily.

And, not to reopen old wounds or restart old fights --- 

RnRS is plainly wrong on (eq? #f '()) ....  that's the biggest
obstacle.

Indeed, after resuming hacking emacs lisp in recent history, I'm
starting to think that the old CL bit of:

	(car nil) => nil
	(cdr nil) => nil

is also not a bad idea.   "Protective errors" are often wrong.

-t




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Marius Vollmer]

Tom Lord <lord@regexps.com> writes:

> 	> Is there no use for thread-independent system-asyncs?
> 
> 	I can't think of any, right now.  
> 
> Any short computation that needs to be invoked asynchronously (say,
> perhaps, driven by a timer) is a candidate.  One can imagine efficient
> I/O working this way, for example; or simple animation of some sort in
> a GUI.

Hmm, I'd like to see these as thread-independent sources of async
activation, not as thread-independent asyncs.  A timer could be
configured to mark a particular async to run in whatever thread is
current when the timer goes off.  Likewise when I/O becomes possible.

Compared to thread-independent asyncs, you will only notice a
difference when there is a thread switch between the time an async is
marked and the original thread next checks for asyncs.  If that ever
becomes a problem, we can make a thread check its asyncs before
switching away from the CPU.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Lynn Winebarger]

On Monday 02 September 2002 18:36, Tom Lord wrote:
>        > If Guile never budges on the stack issue, I would still be
>        > inclined to see it as an implementation optimized for cases
>        > when the C stack is used heavily.
> 
> And, not to reopen old wounds or restart old fights --- 
       
   You were making sense right up until this part.
   
Lynn


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

   >> And, not to reopen old wounds or restart old fights --- 
   >> [#f vs ()]

   > You were making sense right up until this part.


SCM (still?) supports:

	(eq? #f ()) => #t

Guile has:

	(eq? #f '()) => #f


R4RS arguably permits either.

R5RS mandates Guile's behavior.

Old implementations have SCM's behavior (also found in systas scheme).

Common Lisp and Emacs Lisp have SCM's behavior.

A while back I tried to flame the current guile developers into
submission on this point, but they are resiliant against such attacks.
The "restart old fights" bit is in reference to that flame war -- it's
just me obsequiously mentioning the design issue in a hopefully
neutral way.

The SCM behavior described above is correct, if for no other reason
than that's how space aliens do it (see c.l.s. a few months back) :-)

the sometimes silly,
-t


(I really like english: what's the difference between obsequious and
sycophantic?)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

> And, not to reopen old wounds or restart old fights --- 
> 
> RnRS is plainly wrong on (eq? #f '()) ....  that's the biggest
> obstacle.

But to do it anyway.

You keep saying "plainly wrong" which is the most infuriating part.

Seems to me it's *plainly right*.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

> Common Lisp and Emacs Lisp have SCM's behavior.

No, Common Lisp and Emacs Lisp have (eq '() nil) -> t.

> A while back I tried to flame the current guile developers into
> submission on this point, but they are resiliant against such attacks.
> The "restart old fights" bit is in reference to that flame war -- it's
> just me obsequiously mentioning the design issue in a hopefully
> neutral way.

Perhaps they didn't submit, but rather actually *agreed* with the R5RS
editors.

Or is that just totally impossible??




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Rob Browning]

Tom Lord <lord@regexps.com> writes:

> ObPolitics: If you think this is merely a friendly design space
> disagreement, that will work itself out on the merits of which idea
> works out better in practice, think again.

Believe it or not, I was *actually* thinking "I hope no one brings
this up so we can continue with a conversation that *appears* to be
headed in a productive direction."

Oh well.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

       > You keep saying "plainly wrong" which is the most infuriating part.

       > Seems to me it's *plainly right*.


Yes, well...

[very long list of purely anecdotal reasons why you are full of crap
omitted]

None of which is a solid argument that you are wrong.

So there we are.

ObPolitics: If you think this is merely a friendly design space
disagreement, that will work itself out on the merits of which idea
works out better in practice, think again.  Accidental economics of
the situation give significantly greater weight to one side than the
other -- which is an economic bug (at least comperable to standards
for railroad-track sizes; arguably much more serious).

ObPolitics 2: The, arguably politically problematic process by which
the RnRS arose (arises?) also adds lots of noise to any signal that
might be there.

ObPolitics 3: As nearly as I can tell, I'm having much more *fun*
programming in my #f == () implementation than y'all are in your #f !=
() implementation.  Nyah nyah!

ObPolitics 4: a *process* to map out the design space for this an
other issues would be more valuable to me, at this juncture, than
continued contextless argument over this particular design issue.


-t


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

   Perhaps they didn't submit, but rather actually *agreed* with the R5RS
   editors.

   Or is that just totally impossible??


Whatever.  This is very boring.

-t



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

   >> Perhaps they didn't submit, but rather actually *agreed* with the R5RS
   >> editors.

   >> Or is that just totally impossible??


   > Whatever.  This is very boring.


Or is it possible that it is only boring to me, and not to others?

Perhaps it is exciting from some other perspective...have you
considered that?

Your constant argumentation agitates me.

Not.

-t



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

> None of which is a solid argument that you are wrong.

If you don't want flame wars, then don't post trolls.  



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Tom Lord]

   Tom Lord <lord@regexps.com> writes:

   > ObPolitics: If you think this is merely a friendly design space
   > disagreement, that will work itself out on the merits of which idea
   > works out better in practice, think again.

   Believe it or not, I was *actually* thinking "I hope no one brings
   this up so we can continue with a conversation that *appears* to be
   headed in a productive direction."

   Oh well.


Oh gosh, dude.   Please don't take it that way.

I like chatting with the guile developers.

For some greater context on obpolitics, see the arch mailing list
archives at regexps.com, the fsb mailing list archives at crynwr.com,
and I'd be happy to fill you in on anything that's not clear.

Talking with y'all has been generally productive, at least for me.
Sorry if it isn't for you -- that's not my intent.

Gnu Cash made newsforge recently -- congrats!

Practical guile applications actually give me a little hope :-)

Lillypond makes me (please forgive the vulgarity) cream my jeans.

-t



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Lynn Winebarger]

On Monday 02 September 2002 20:27, Rob Browning wrote:
> Tom Lord <lord@regexps.com> writes:
> 
> > ObPolitics: If you think this is merely a friendly design space
> > disagreement, that will work itself out on the merits of which idea
> > works out better in practice, think again.
> 
> Believe it or not, I was *actually* thinking "I hope no one brings
> this up so we can continue with a conversation that *appears* to be
> headed in a productive direction."

    I agree, it was headed in a good direction (actually right towards
the subject of the "Stack SIze?" thread on guile-user).
     What is the upper limit on the trouble Guile users could be made
to deal with vis-a-vis garbage collection, in particular, precise
generational,copying,compacting garbage collection?  They apparently
have to go to some trouble now to make sure the compiler doesn't
optimize SCM's off the stack.  Would it be too much to have them
explicitly declare the lifetimes of these SCMs (alternatively, to insure
they are accessible from some known root)?  Or to make them
not hide SCM's in other values in the un-preprocessed source
(so we could write a pass to analyze types for the GC to use)?
     Yeah, I know, it's all blue sky.
     As long as we're at it, I'd like the C continuation semantics to 
be that you can't return from a C function twice, but otherwise
you can jump back and forth between Scheme code even
if you returned through the C function once.  There's really
no reason to pretend C functions have anything like a real
continuation, so we shouldn't have to go to special lengths
to support them (ok, keep around the old behaviour for those
who really,really want it applied to specific functions that are
written specifically to be valid: i.e. they guarantee no resources
in use (other than the ones on the stack, which are maintained
by the copying) are explicitly freed by their return.
      As for the rest, I think we should make C functions
declare themselves as primitives that never call Scheme,
and "other", that might call eval.  The first could use some
fixed "scratch" stack space, the others should get a freshly
allocated stack (whose size they declare through snarfage
or somesuch).  The interpreter could then analyze the
scheme code to find regions "between" call/cc's that could
use some fixed stack.  Call/cc's allocate a fresh Scheme
stack for the "next" block of code that gets executed.
    Is that enough to get us back on track?


ObGripe:  Pick one mailing list or the other.  

Lynn
 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Threads and asyncs

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Also, a thread would wake up when it is blocked and run its asyncs
> anyway.

I'd like to draw your attention to this.  What do you think of it?

When a thread blocks to wait for a mutex, say, it will wake up when a
async is marked for it and run that async.  Then it will go to sleep
again (unless it has acquired the mutex).  Likewise for condition
variables, select and other kind of blocks.

Also, I think we need a single mechanism that can block on multiple
objects.  For that, we should probably extend 'select' to also handle
mutixes, condition variables, thread joins, and maybe other things.

I have made asyncs per-thread in my working copy and they work fine.
I have also added 'current-thread' and 'all-threads' functions, which
I think are useful.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Threads and asyncs

[NIIBE Yutaka]

In threaded applications, we should avoid "asynchronous" signal
handling.  This is some sort of common technique/discipline, I think.

If we do want asynchronous signal handling in threaded applications,
we'll open can of dead-lock worms.  Signal handler will access some
shared data to affect some thread control, which means, need some
mutual exclusion for that.  What if when signal hander will be invoked
asynchronously in the critical region?  Signal handler cannot get the
lock.  That'll be cause of the dead lock(s).

(Usually) In threaded applications, signal is handled synchronously, 
by assigning a dedicated thread for signal handling.  I mean, a thread
like that:
		while (1)
		  {
		    switch (get_signal ()) /* Blocked if none */
		     {
		    case SIGINT:
			sigint_handler ();
			break;
		    case SIGHUP:
			sighup_handler ();
			break;
		    /* ... */
		     }
		  }
-- 


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Threads and asyncs

[Marius Vollmer]

NIIBE Yutaka <gniibe@m17n.org> writes:

> If we do want asynchronous signal handling in threaded applications,
> we'll open can of dead-lock worms.

Asyncronous signals are also a clean way to break up a dead-lock.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Threads and asyncs

[NIIBE Yutaka]

Marius Vollmer wrote:
 > Asyncronous signals are also a clean way to break up a dead-lock.

Well, yup, it's convenient to break up dead-lock by some interruption
scheme.  That's true.  However, I think that it's not UNIX signal and
its signal handler, in general.  Definitely not.

I think that we're talking about Guile language support for UNIX
siganls and threads.  In this case, we need to think about the
semantics of UNIX signals with thread library.  Please refer some
thread programming introduction(s) for UNIX signal.

	http://www.serpentine.com/~bos/threads-faq/
	Bil Lewis and Daniel J. Berg, Multithreaded Programming with Pthread

Or else, looking the implementation such as Python would help.
-- 


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel