10 minutes ago, Tony Garnock-Jones wrote:
> On 2011-10-22 9:53 PM, Eli Barzilay wrote:
> > I'm not following "may not have been started via `delay/thread'"
> > -- in your example you also need to define a new `standard-thread'
> > to start them, so you need something other than `thread' anyway.
>
On 2011-10-22 9:53 PM, Eli Barzilay wrote:
> I'm not following "may not have been started via `delay/thread'" -- in
> your example you also need to define a new `standard-thread' to start
> them, so you need something other than `thread' anyway.
You're right. Using standard-thread would let me sim
Four hours ago, Tony Garnock-Jones wrote:
> On 2011-10-22 5:10 PM, Eli Barzilay wrote:
> > I don't see how why that cannot be built on top of `delay/thread'.
>
> Because
> 1. the threads may not have been started via delay/thread, and
> 2. there is no way to get from (current-thread) to the promis
On 2011-10-22 5:10 PM, Eli Barzilay wrote:
> I don't see how why that cannot be built on top of `delay/thread'.
Because
1. the threads may not have been started via delay/thread, and
2. there is no way to get from (current-thread) to the promise.
My best bet so far seems to be something along the
An hour and a half ago, Tony Garnock-Jones wrote:
> On 2011-10-22 1:27 PM, Eli Barzilay wrote:
> > Sound like `delay/thread' might be doing everything you need.
>
> That's a neat thing, but it's not quite what I'm after. I have a
> collection of threads that are started independently and later sta
On 2011-10-22 1:27 PM, Eli Barzilay wrote:
> Sound like `delay/thread' might be doing everything you need.
That's a neat thing, but it's not quite what I'm after. I have a
collection of threads that are started independently and later start
communicating via some shared medium. The shared medium n
Sound like `delay/thread' might be doing everything you need.
On Oct 22, 2011, at 9:54 AM, Tony Garnock-Jones wrote:
> Hi all,
>
> What do people think of the idea of threads preserving their exit status?
>
> The exit status would be either
> - a raised exception, or
> - a normally-returne
On 2011-10-22 12:02 PM, Jay McCarthy wrote:
> Eh, I think imposing this on all the threads would be a bad idea
> because it would increase memory usage unexpectedly for a lot of
> programs, I would guess
Only those holding references to their threads well beyond the lifetime
of said threads. Is th
On Sat, Oct 22, 2011 at 9:33 AM, Tony Garnock-Jones wrote:
> On 2011-10-22 11:14 AM, Jay McCarthy wrote:
>> I don't think any change is necessary, because this can be done as a library:
>> https://github.com/jeapostrophe/exp/blob/master/ethread.rkt
>
> I was hoping for something that works for thr
On 2011-10-22 11:14 AM, Jay McCarthy wrote:
> I don't think any change is necessary, because this can be done as a library:
> https://github.com/jeapostrophe/exp/blob/master/ethread.rkt
I was hoping for something that works for threads created using (thread)
as well. Using either your approach or
I don't think any change is necessary, because this can be done as a library:
https://github.com/jeapostrophe/exp/blob/master/ethread.rkt
On Sat, Oct 22, 2011 at 8:54 AM, Tony Garnock-Jones wrote:
> Hi all,
>
> What do people think of the idea of threads preserving their exit status?
>
> The exi
Hi all,
What do people think of the idea of threads preserving their exit status?
The exit status would be either
- a raised exception, or
- a normally-returned value, or
- nothing as yet, because the thread is still running.
(thread-died-with-exception? thd) -> boolean?
Returns #t if th
12 matches
Mail list logo
