This is going to sound like a daft question, but: is there any reason
that the thread that calls 'touch' needs to be the same thread that
calls its continuation?
I.e. why does there need to be a special "main thread"? Can't "picking
up a job blocking on touch" just be another task allocated to th
Hi!
nalaginrut skribis:
> I switch to lua branch then compiled it and try, seems some bugs there,
> it can't run successfully:
> ---cut
> scheme@(guile-user)> ,L lua
> Happy hacking with Lua! To switch back, type `,L scheme'.
> lua@(guile-user)> x=1
Maybe yo
Hi Peter,
Peter TB Brett skribis:
> This is going to sound like a daft question, but: is there any reason
> that the thread that calls 'touch' needs to be the same thread that
> calls its continuation?
>
> I.e. why does there need to be a special "main thread"? Can't "picking
> up a job blockin
Hi,
> In terms of strategy, I think Guile’s focus should remain primarily on
> Scheme variants, and ELisp. Other language front-ends are of course
> welcome, but we must keep an eye on what the demand is.
What about common lisp is scheme a lisp or is CL a scheme :-)
Anyway to support CL I would
l...@gnu.org (Ludovic Courtès) writes:
> Hi Peter,
>
> Peter TB Brett skribis:
>
>> This is going to sound like a daft question, but: is there any reason
>> that the thread that calls 'touch' needs to be the same thread that
>> calls its continuation?
>>
>> I.e. why does there need to be a specia
Hi,
Peter TB Brett skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Peter,
>>
>> Peter TB Brett skribis:
>>
>>> This is going to sound like a daft question, but: is there any reason
>>> that the thread that calls 'touch' needs to be the same thread that
>>> calls its continuation?
>>>
l...@gnu.org (Ludovic Courtès) skribis:
> Mark H Weaver skribis:
>
>> I guess the one remaining concern I have is that if there are any
>> long-running futures in the process, then any 'touch' could take a very
>> long time to complete, even if the future it is waiting for is a very
>> short job.
