* Re: Threads and asyncs [not found] <87it1oglmq.fsf@zagadka.ping.de> @ 2002-09-02 21:24 ` Tom Lord [not found] ` <200209022124.OAA07625@morrowfield.regexps.com> ` (2 subsequent siblings) 3 siblings, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-02 21:24 UTC (permalink / raw) Cc: guile-devel, guile-user > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <200209022124.OAA07625@morrowfield.regexps.com>]
* Re: Threads and asyncs [not found] ` <200209022124.OAA07625@morrowfield.regexps.com> @ 2002-09-02 21:53 ` Marius Vollmer 2002-09-02 22:24 ` Tom Lord [not found] ` <200209022224.PAA07962@morrowfield.regexps.com> 2002-09-02 23:02 ` Rob Browning [not found] ` <87k7m43si7.fsf@raven.i.defaultvalue.org> 2 siblings, 2 replies; 24+ messages in thread From: Marius Vollmer @ 2002-09-02 21:53 UTC (permalink / raw) Cc: guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs 2002-09-02 21:53 ` Marius Vollmer @ 2002-09-02 22:24 ` Tom Lord [not found] ` <200209022224.PAA07962@morrowfield.regexps.com> 1 sibling, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-02 22:24 UTC (permalink / raw) Cc: guile-devel, guile-user > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <200209022224.PAA07962@morrowfield.regexps.com>]
* Re: Threads and asyncs [not found] ` <200209022224.PAA07962@morrowfield.regexps.com> @ 2002-09-02 23:51 ` Marius Vollmer 0 siblings, 0 replies; 24+ messages in thread From: Marius Vollmer @ 2002-09-02 23:51 UTC (permalink / raw) Cc: guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs [not found] ` <200209022124.OAA07625@morrowfield.regexps.com> 2002-09-02 21:53 ` Marius Vollmer @ 2002-09-02 23:02 ` Rob Browning [not found] ` <87k7m43si7.fsf@raven.i.defaultvalue.org> 2 siblings, 0 replies; 24+ messages in thread From: Rob Browning @ 2002-09-02 23:02 UTC (permalink / raw) Cc: mvo, guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <87k7m43si7.fsf@raven.i.defaultvalue.org>]
* Re: Threads and asyncs [not found] ` <87k7m43si7.fsf@raven.i.defaultvalue.org> @ 2002-09-02 23:24 ` Tom Lord [not found] ` <200209022324.QAA08246@morrowfield.regexps.com> 1 sibling, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-02 23:24 UTC (permalink / raw) Cc: guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <200209022324.QAA08246@morrowfield.regexps.com>]
* Re: Threads and asyncs [not found] ` <200209022324.QAA08246@morrowfield.regexps.com> @ 2002-09-02 23:36 ` Tom Lord [not found] ` <200209022336.QAA08304@morrowfield.regexps.com> 1 sibling, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-02 23:36 UTC (permalink / raw) Cc: 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <200209022336.QAA08304@morrowfield.regexps.com>]
* Re: Threads and asyncs [not found] ` <200209022336.QAA08304@morrowfield.regexps.com> @ 2002-09-02 23:52 ` Lynn Winebarger [not found] ` <0209021852361X.19624@locke.free-expression.org> 2002-09-03 1:00 ` Thomas Bushnell, BSG 2 siblings, 0 replies; 24+ messages in thread From: Lynn Winebarger @ 2002-09-02 23:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <0209021852361X.19624@locke.free-expression.org>]
* Re: Threads and asyncs [not found] ` <0209021852361X.19624@locke.free-expression.org> @ 2002-09-03 0:57 ` Tom Lord [not found] ` <200209030057.RAA08617@morrowfield.regexps.com> 1 sibling, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-03 0:57 UTC (permalink / raw) Cc: rlb, guile-devel, guile-user >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <200209030057.RAA08617@morrowfield.regexps.com>]
* Re: Threads and asyncs [not found] ` <200209030057.RAA08617@morrowfield.regexps.com> @ 2002-09-03 1:13 ` Thomas Bushnell, BSG [not found] ` <87admzub73.fsf@becket.becket.net> 1 sibling, 0 replies; 24+ messages in thread From: Thomas Bushnell, BSG @ 2002-09-03 1:13 UTC (permalink / raw) Cc: owinebar, rlb, guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <87admzub73.fsf@becket.becket.net>]
* Re: Threads and asyncs [not found] ` <87admzub73.fsf@becket.becket.net> @ 2002-09-03 1:29 ` Tom Lord 2002-09-03 1:31 ` Tom Lord 1 sibling, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-03 1:29 UTC (permalink / raw) Cc: owinebar, rlb, guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs [not found] ` <87admzub73.fsf@becket.becket.net> 2002-09-03 1:29 ` Tom Lord @ 2002-09-03 1:31 ` Tom Lord 1 sibling, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-03 1:31 UTC (permalink / raw) Cc: owinebar, rlb, guile-devel, guile-user >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs [not found] ` <200209022336.QAA08304@morrowfield.regexps.com> 2002-09-02 23:52 ` Lynn Winebarger [not found] ` <0209021852361X.19624@locke.free-expression.org> @ 2002-09-03 1:00 ` Thomas Bushnell, BSG 2 siblings, 0 replies; 24+ messages in thread From: Thomas Bushnell, BSG @ 2002-09-03 1:00 UTC (permalink / raw) Cc: rlb, guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <87ptvvubst.fsf@becket.becket.net>]
[parent not found: <200209030128.SAA08719@morrowfield.regexps.com>]
* RnRS process/history/documentation (was Re: Threads and asyncs) [not found] ` <200209030128.SAA08719@morrowfield.regexps.com> @ 2002-09-03 1:23 ` Lynn Winebarger 2002-09-03 1:27 ` Threads and asyncs Rob Browning ` (2 subsequent siblings) 3 siblings, 0 replies; 24+ messages in thread From: Lynn Winebarger @ 2002-09-03 1:23 UTC (permalink / raw) Cc: rlb, guile-devel, guile-user On Monday 02 September 2002 20:28, Tom Lord wrote: > 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. I've found reading the rrrs-authors archives from http://www.swiss.ai.mit.edu/projects/scheme/rrrs-archive.html very enlightening. Too bad it stops at 1998. For example, it reveals why Guile has the macro expansion problems it has. Maybe a pointer to that archive should go up on the Guile webpage somewhere. Lynn _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs [not found] ` <200209030128.SAA08719@morrowfield.regexps.com> 2002-09-03 1:23 ` RnRS process/history/documentation (was Re: Threads and asyncs) Lynn Winebarger @ 2002-09-03 1:27 ` Rob Browning 2002-09-03 1:34 ` Thomas Bushnell, BSG [not found] ` <87u1l73ls1.fsf@raven.i.defaultvalue.org> 3 siblings, 0 replies; 24+ messages in thread From: Rob Browning @ 2002-09-03 1:27 UTC (permalink / raw) Cc: tb, guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs [not found] ` <200209030128.SAA08719@morrowfield.regexps.com> 2002-09-03 1:23 ` RnRS process/history/documentation (was Re: Threads and asyncs) Lynn Winebarger 2002-09-03 1:27 ` Threads and asyncs Rob Browning @ 2002-09-03 1:34 ` Thomas Bushnell, BSG [not found] ` <87u1l73ls1.fsf@raven.i.defaultvalue.org> 3 siblings, 0 replies; 24+ messages in thread From: Thomas Bushnell, BSG @ 2002-09-03 1:34 UTC (permalink / raw) Cc: rlb, guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <87u1l73ls1.fsf@raven.i.defaultvalue.org>]
* Re: Threads and asyncs [not found] ` <87u1l73ls1.fsf@raven.i.defaultvalue.org> @ 2002-09-03 1:45 ` Tom Lord 2002-09-03 1:48 ` Lynn Winebarger 1 sibling, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-03 1:45 UTC (permalink / raw) Cc: tb, guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs [not found] ` <87u1l73ls1.fsf@raven.i.defaultvalue.org> 2002-09-03 1:45 ` Tom Lord @ 2002-09-03 1:48 ` Lynn Winebarger 1 sibling, 0 replies; 24+ messages in thread From: Lynn Winebarger @ 2002-09-03 1:48 UTC (permalink / raw) Cc: tb, guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs [not found] ` <87ptvvubst.fsf@becket.becket.net> [not found] ` <200209030128.SAA08719@morrowfield.regexps.com> @ 2002-09-03 1:28 ` Tom Lord 1 sibling, 0 replies; 24+ messages in thread From: Tom Lord @ 2002-09-03 1:28 UTC (permalink / raw) Cc: rlb, guile-devel, guile-user > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs [not found] <87it1oglmq.fsf@zagadka.ping.de> ` (2 preceding siblings ...) [not found] ` <87ptvvubst.fsf@becket.becket.net> @ 2002-09-03 18:06 ` Marius Vollmer 2002-09-04 0:28 ` NIIBE Yutaka 3 siblings, 1 reply; 24+ messages in thread From: Marius Vollmer @ 2002-09-03 18:06 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs 2002-09-03 18:06 ` Marius Vollmer @ 2002-09-04 0:28 ` NIIBE Yutaka 2002-09-04 18:02 ` Marius Vollmer 0 siblings, 1 reply; 24+ messages in thread From: NIIBE Yutaka @ 2002-09-04 0:28 UTC (permalink / raw) Cc: guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs 2002-09-04 0:28 ` NIIBE Yutaka @ 2002-09-04 18:02 ` Marius Vollmer 2002-09-04 22:30 ` NIIBE Yutaka 0 siblings, 1 reply; 24+ messages in thread From: Marius Vollmer @ 2002-09-04 18:02 UTC (permalink / raw) Cc: guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Threads and asyncs 2002-09-04 18:02 ` Marius Vollmer @ 2002-09-04 22:30 ` NIIBE Yutaka 0 siblings, 0 replies; 24+ messages in thread From: NIIBE Yutaka @ 2002-09-04 22:30 UTC (permalink / raw) Cc: guile-devel, guile-user 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Threads and asyncs @ 2002-09-02 20:52 Marius Vollmer 0 siblings, 0 replies; 24+ messages in thread From: Marius Vollmer @ 2002-09-02 20:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2002-09-04 22:30 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87it1oglmq.fsf@zagadka.ping.de>
2002-09-02 21:24 ` Threads and asyncs Tom Lord
[not found] ` <200209022124.OAA07625@morrowfield.regexps.com>
2002-09-02 21:53 ` Marius Vollmer
2002-09-02 22:24 ` Tom Lord
[not found] ` <200209022224.PAA07962@morrowfield.regexps.com>
2002-09-02 23:51 ` Marius Vollmer
2002-09-02 23:02 ` Rob Browning
[not found] ` <87k7m43si7.fsf@raven.i.defaultvalue.org>
2002-09-02 23:24 ` Tom Lord
[not found] ` <200209022324.QAA08246@morrowfield.regexps.com>
2002-09-02 23:36 ` Tom Lord
[not found] ` <200209022336.QAA08304@morrowfield.regexps.com>
2002-09-02 23:52 ` Lynn Winebarger
[not found] ` <0209021852361X.19624@locke.free-expression.org>
2002-09-03 0:57 ` Tom Lord
[not found] ` <200209030057.RAA08617@morrowfield.regexps.com>
2002-09-03 1:13 ` Thomas Bushnell, BSG
[not found] ` <87admzub73.fsf@becket.becket.net>
2002-09-03 1:29 ` Tom Lord
2002-09-03 1:31 ` Tom Lord
2002-09-03 1:00 ` Thomas Bushnell, BSG
[not found] ` <87ptvvubst.fsf@becket.becket.net>
[not found] ` <200209030128.SAA08719@morrowfield.regexps.com>
2002-09-03 1:23 ` RnRS process/history/documentation (was Re: Threads and asyncs) Lynn Winebarger
2002-09-03 1:27 ` Threads and asyncs Rob Browning
2002-09-03 1:34 ` Thomas Bushnell, BSG
[not found] ` <87u1l73ls1.fsf@raven.i.defaultvalue.org>
2002-09-03 1:45 ` Tom Lord
2002-09-03 1:48 ` Lynn Winebarger
2002-09-03 1:28 ` Tom Lord
2002-09-03 18:06 ` Marius Vollmer
2002-09-04 0:28 ` NIIBE Yutaka
2002-09-04 18:02 ` Marius Vollmer
2002-09-04 22:30 ` NIIBE Yutaka
2002-09-02 20:52 Marius Vollmer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).