The equivalent of racket's break-thread in guile?

The equivalent of racket's break-thread in guile?

[Xin Wang]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

In Racket, break-thread is used to send an break exception to a thread[1].

E. g.

(let ((th (thread (lambda ()
            (dynamic-wind
              (lambda () #t)
              (lambda () (/ 1 0))
              (lambda () (sleep 5) (display "out-guard\n")))))))

  (sleep 1)
  (break-thread th))

For above code, out-guard part of dynmaic-wind will not be interrupted if
use break-thread to cancel a thread, and kill-thread will cancel thread
immediately.

In Guile, the equivalent of kill-thread is cancel-thread, and is there any
equivalent of break-thread?

[1] http://docs.racket-lang.org/reference/breakhandler.html

Regards,
Xin Wang

[-- Attachment #2: Type: text/html, Size: 1086 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Nala Ginrut]

On Fri, 2013-05-31 at 07:40 +0800, Xin Wang wrote:
> In Racket, break-thread is used to send an break exception to a thread[1].
> 
> E. g.
> 
> (let ((th (thread (lambda ()
>             (dynamic-wind
>               (lambda () #t)
>               (lambda () (/ 1 0))
>               (lambda () (sleep 5) (display "out-guard\n")))))))
> 
>   (sleep 1)
>   (break-thread th))
> 
> For above code, out-guard part of dynmaic-wind will not be interrupted if
> use break-thread to cancel a thread, and kill-thread will cancel thread
> immediately.
> 
> In Guile, the equivalent of kill-thread is cancel-thread, and is there any
> equivalent of break-thread?
> 
> [1] http://docs.racket-lang.org/reference/breakhandler.html
> 

I think the answer is NO.

The thread in Racket is green-thread which is implemented by some kind
of stack-copying. That's why its thread could receive the so-called
'break signal'. The scheduler is in the VM rather than OS.
But the traditional thread in Guile is based on pthread. So they are
very different. 
Anyway, I'm trying to write green-thread based on delimited-continuation
which will be used for an Actor-model implementation.


> Regards,
> Xin Wang

Re: The equivalent of racket's break-thread in guile?

[Xin Wang]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

2013/5/31 Nala Ginrut <nalaginrut@gmail.com>

> On Fri, 2013-05-31 at 07:40 +0800, Xin Wang wrote:
> > In Racket, break-thread is used to send an break exception to a
> thread[1].
> >
> > E. g.
> >
> > (let ((th (thread (lambda ()
> >             (dynamic-wind
> >               (lambda () #t)
> >               (lambda () (/ 1 0))
> >               (lambda () (sleep 5) (display "out-guard\n")))))))
> >
> >   (sleep 1)
> >   (break-thread th))
> >
> > For above code, out-guard part of dynmaic-wind will not be interrupted if
> > use break-thread to cancel a thread, and kill-thread will cancel thread
> > immediately.
> >
> > In Guile, the equivalent of kill-thread is cancel-thread, and is there
> any
> > equivalent of break-thread?
> >
> > [1] http://docs.racket-lang.org/reference/breakhandler.html
> >
>
> I think the answer is NO.
>
> The thread in Racket is green-thread which is implemented by some kind
> of stack-copying. That's why its thread could receive the so-called
> 'break signal'. The scheduler is in the VM rather than OS.
> But the traditional thread in Guile is based on pthread. So they are
> very different.
> Anyway, I'm trying to write green-thread based on delimited-continuation
> which will be used for an Actor-model implementation.
>
>
Thank you for pointing out this.

After some more search, I found that pthread has function pthread_kill [1],
which can be used to send signal to specific thread.

No sure if it can be used to implement similar behaviour.

[1]
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html



>
> > Regards,
> > Xin Wang
>
>
>

[-- Attachment #2: Type: text/html, Size: 2651 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Nala Ginrut]

On Fri, 2013-05-31 at 14:24 +0800, Xin Wang wrote:

> 
> 
> Thank you for pointing out this.
> 
> 
> After some more search, I found that pthread has function pthread_kill
> [1], which can be used to send signal to specific thread.
> 
> 
> No sure if it can be used to implement similar behaviour.
> 
> 
> [1]
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html


At least in Linux, pthread_kill may effect the whole process:
----------------------------cut----------------------------------
Signal  dispositions  are  process-wide: if a signal handler is
installed, the handler will be invoked in the thread thread,
but if the disposition of the signal is "stop", "continue", or
"terminate", this action will affect the whole process.
----------------------------end----------------------------------

The real solution for your purpose is green-thread IMO.


>  
>         
>         > Regards,
>         > Xin Wang
>         
>         
> 
> 

Re: The equivalent of racket's break-thread in guile?

[Xin Wang]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

2013/5/31 Nala Ginrut <nalaginrut@gmail.com>

> On Fri, 2013-05-31 at 14:24 +0800, Xin Wang wrote:
>
> >
> >
> > Thank you for pointing out this.
> >
> >
> > After some more search, I found that pthread has function pthread_kill
> > [1], which can be used to send signal to specific thread.
> >
> >
> > No sure if it can be used to implement similar behaviour.
> >
> >
> > [1]
> >
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html
>
>
> At least in Linux, pthread_kill may effect the whole process:
> ----------------------------cut----------------------------------
> Signal  dispositions  are  process-wide: if a signal handler is
> installed, the handler will be invoked in the thread thread,
> but if the disposition of the signal is "stop", "continue", or
> "terminate", this action will affect the whole process.
> ----------------------------end----------------------------------
>
> The real solution for your purpose is green-thread IMO.
>
>
I see.

But I think it is still doable, although not elegant.

We can establish a signal handler to exit specific thread instead of a
global terminate disposition, and then in thread pthread_sigmask() can be
used to block that signal temporarily, before calling out-guard part of
dynamic-wind.

Some sample C code: https://gist.github.com/dram/5683646



> >
> >
> >         > Regards,
> >         > Xin Wang
> >
> >
> >
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 2415 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Xin Wang]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

2013/5/31 Xin Wang <dram.wang@gmail.com>

>
>
>
> 2013/5/31 Nala Ginrut <nalaginrut@gmail.com>
>
>> On Fri, 2013-05-31 at 14:24 +0800, Xin Wang wrote:
>>
>> >
>> >
>> > Thank you for pointing out this.
>> >
>> >
>> > After some more search, I found that pthread has function pthread_kill
>> > [1], which can be used to send signal to specific thread.
>> >
>> >
>> > No sure if it can be used to implement similar behaviour.
>> >
>> >
>> > [1]
>> >
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html
>>
>>
>> At least in Linux, pthread_kill may effect the whole process:
>> ----------------------------cut----------------------------------
>> Signal  dispositions  are  process-wide: if a signal handler is
>> installed, the handler will be invoked in the thread thread,
>> but if the disposition of the signal is "stop", "continue", or
>> "terminate", this action will affect the whole process.
>> ----------------------------end----------------------------------
>>
>> The real solution for your purpose is green-thread IMO.
>>
>>
> I see.
>
> But I think it is still doable, although not elegant.
>
> We can establish a signal handler to exit specific thread instead of a
> global terminate disposition, and then in thread pthread_sigmask() can be
> used to block that signal temporarily, before calling out-guard part of
> dynamic-wind.
>
> Some sample C code: https://gist.github.com/dram/5683646
>
>
I think I have found a much simpler method.

pthread_cancel request can be blocked by pthread_setcancelstate.

See code for more info: https://gist.github.com/dram/5684164


>
>> >
>> >
>> >         > Regards,
>> >         > Xin Wang
>> >
>> >
>> >
>> >
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3376 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Chaos Eternal]

IMHO, that means if you send a signal other than SIGSTOP SIGCONT
SIGKILL or SIGTERM, the signal will not affect the whole process.
also, SIGSTOP/SIGCONT and SIGKILL are un-catchable signals, they are
not offten used.
according the pthread_kill(3), you can send arbitrary signal to a
thread and, according to guile's manual, such signals can be catched.
they are just asyncs.

references:
pthread_kill(3)
6.21.2.1 System asyncs of guile manual.

On Fri, May 31, 2013 at 2:55 PM, Nala Ginrut <nalaginrut@gmail.com> wrote:
> On Fri, 2013-05-31 at 14:24 +0800, Xin Wang wrote:
>
>>
>>
>> Thank you for pointing out this.
>>
>>
>> After some more search, I found that pthread has function pthread_kill
>> [1], which can be used to send signal to specific thread.
>>
>>
>> No sure if it can be used to implement similar behaviour.
>>
>>
>> [1]
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html
>
>
> At least in Linux, pthread_kill may effect the whole process:
> ----------------------------cut----------------------------------
> Signal  dispositions  are  process-wide: if a signal handler is
> installed, the handler will be invoked in the thread thread,
> but if the disposition of the signal is "stop", "continue", or
> "terminate", this action will affect the whole process.
> ----------------------------end----------------------------------
>
> The real solution for your purpose is green-thread IMO.
>
>
>>
>>
>>         > Regards,
>>         > Xin Wang
>>
>>
>>
>>
>
>
>

Re: The equivalent of racket's break-thread in guile?

[Xin Wang]

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

2013/5/31 Chaos Eternal <chaoseternal@shlug.org>

> IMHO, that means if you send a signal other than SIGSTOP SIGCONT
> SIGKILL or SIGTERM, the signal will not affect the whole process.
> also, SIGSTOP/SIGCONT and SIGKILL are un-catchable signals, they are
> not offten used.
> according the pthread_kill(3), you can send arbitrary signal to a
> thread and, according to guile's manual, such signals can be catched.
> they are just asyncs.
>
> references:
> pthread_kill(3)
> 6.21.2.1 System asyncs of guile manual.
>

I think there are two things that are global in pthread of linux:

1. signal handlers, there no corresponding pthread version of sigaction, so
we can only establish signal handlers globally.
2. singals that take disposition of "stop", "continue", "terminate" will
effect whole process. signal(7) descrriables default dispositions of
signals.

So for example, if we do not catch SIGUSR1, it will kill the whole process,
as its default action is terminate, and if we catch SIGTERM, it will not
affect whole process.


>
> On Fri, May 31, 2013 at 2:55 PM, Nala Ginrut <nalaginrut@gmail.com> wrote:
> > On Fri, 2013-05-31 at 14:24 +0800, Xin Wang wrote:
> >
> >>
> >>
> >> Thank you for pointing out this.
> >>
> >>
> >> After some more search, I found that pthread has function pthread_kill
> >> [1], which can be used to send signal to specific thread.
> >>
> >>
> >> No sure if it can be used to implement similar behaviour.
> >>
> >>
> >> [1]
> >>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html
> >
> >
> > At least in Linux, pthread_kill may effect the whole process:
> > ----------------------------cut----------------------------------
> > Signal  dispositions  are  process-wide: if a signal handler is
> > installed, the handler will be invoked in the thread thread,
> > but if the disposition of the signal is "stop", "continue", or
> > "terminate", this action will affect the whole process.
> > ----------------------------end----------------------------------
> >
> > The real solution for your purpose is green-thread IMO.
> >
> >
> >>
> >>
> >>         > Regards,
> >>         > Xin Wang
> >>
> >>
> >>
> >>
> >
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 3373 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Ludovic Courtès]

Xin Wang <dram.wang@gmail.com> skribis:

> In Guile, the equivalent of kill-thread is cancel-thread, and is there any
> equivalent of break-thread?
>
> [1] http://docs.racket-lang.org/reference/breakhandler.html

If I understand correctly, “breaks” are similar to Guile’s “asyncs”
(info "(guile) Asyncs").

However, I don’t understand what you’re trying to achieve.  Could you
give another example of the behavior you’re after?

Thanks,
Ludo’.

Re: The equivalent of racket's break-thread in guile?

[Xin Wang]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

2013/5/31 Ludovic Courtès <ludo@gnu.org>

> Xin Wang <dram.wang@gmail.com> skribis:
>
> > In Guile, the equivalent of kill-thread is cancel-thread, and is there
> any
> > equivalent of break-thread?
> >
> > [1] http://docs.racket-lang.org/reference/breakhandler.html
>
> If I understand correctly, “breaks” are similar to Guile’s “asyncs”
> (info "(guile) Asyncs").
>
> However, I don’t understand what you’re trying to achieve.  Could you
> give another example of the behavior you’re after?
>
>
I was reading source code of Arc language[1], and wondering if it is
possible to port it to Guile.

It define a function to handle HTTP request in srv.arc(L48):

(def handle-request-1 (s)
  --- pruned ---
            (with (th1 nil th2 nil)
              (= th1 (thread
                       (after (handle-request-thread i o ip)
                              (close i o)
                              (kill-thread th2))))
              (= th2 (thread
                       (sleep threadlife*)
                       (unless (dead th1)
                         (prn "srv thread took too long for " ip))
                       (break-thread th1)
                       (force-close i o))))))))

It create two threads to handle a request, one do main stuff and anthor one
wait to kill first one if it takes too much time.

Although I'm not quite sure, I think one reason to use 'kill-thread' and
'break-thread' differently is to make sure that exception handler function
is fully executed. ('after' is implemented by  dynamic-wind).

[1] http://ycombinator.com/arc/*arc3.1.tar*


> Thanks,
> Ludo’.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2591 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

If you just need to handle HTTP request or build webapp, I suggest you use
my web framework Artanis. It uses Guile inner sever based on thread.
在 2013-6-2 AM7:49，"Xin Wang" <dram.wang@gmail.com>写道：

>
>
>
> 2013/5/31 Ludovic Courtès <ludo@gnu.org>
>
>> Xin Wang <dram.wang@gmail.com> skribis:
>>
>> > In Guile, the equivalent of kill-thread is cancel-thread, and is there
>> any
>> > equivalent of break-thread?
>> >
>> > [1] http://docs.racket-lang.org/reference/breakhandler.html
>>
>> If I understand correctly, “breaks” are similar to Guile’s “asyncs”
>> (info "(guile) Asyncs").
>>
>> However, I don’t understand what you’re trying to achieve.  Could you
>> give another example of the behavior you’re after?
>>
>>
> I was reading source code of Arc language[1], and wondering if it is
> possible to port it to Guile.
>
> It define a function to handle HTTP request in srv.arc(L48):
>
> (def handle-request-1 (s)
>   --- pruned ---
>             (with (th1 nil th2 nil)
>               (= th1 (thread
>                        (after (handle-request-thread i o ip)
>                               (close i o)
>                               (kill-thread th2))))
>               (= th2 (thread
>                        (sleep threadlife*)
>                        (unless (dead th1)
>                          (prn "srv thread took too long for " ip))
>                        (break-thread th1)
>                        (force-close i o))))))))
>
> It create two threads to handle a request, one do main stuff and anthor
> one wait to kill first one if it takes too much time.
>
> Although I'm not quite sure, I think one reason to use 'kill-thread' and
> 'break-thread' differently is to make sure that exception handler function
> is fully executed. ('after' is implemented by  dynamic-wind).
>
> [1] http://ycombinator.com/arc/*arc3.1.tar*
>
>
>> Thanks,
>> Ludo’.
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3312 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Xin Wang]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

2013/6/2 Nala Ginrut <nalaginrut@gmail.com>

> If you just need to handle HTTP request or build webapp, I suggest you use
> my web framework Artanis. It uses Guile inner sever based on thread.
>

Thanks, I'll have a look at it.

Recently I need to deploy a Hacker News[1] like service. Paul Graham has
released its source with Arc.

PG has not release updated versions for several years, so I think I will
need to maintain and fix bugs by myself, and I'd prefer to do such things
in Guile instead of Racket.

Currently I'll use Racket to run this service, and it would be great if it
can be replaced by Guile eventually.

[1] https://news.ycombinator.com/



> 在 2013-6-2 AM7:49，"Xin Wang" <dram.wang@gmail.com>写道：
>
>
>>
>>
>> 2013/5/31 Ludovic Courtès <ludo@gnu.org>
>>
>>> Xin Wang <dram.wang@gmail.com> skribis:
>>>
>>> > In Guile, the equivalent of kill-thread is cancel-thread, and is there
>>> any
>>> > equivalent of break-thread?
>>> >
>>> > [1] http://docs.racket-lang.org/reference/breakhandler.html
>>>
>>> If I understand correctly, “breaks” are similar to Guile’s “asyncs”
>>> (info "(guile) Asyncs").
>>>
>>> However, I don’t understand what you’re trying to achieve.  Could you
>>> give another example of the behavior you’re after?
>>>
>>>
>> I was reading source code of Arc language[1], and wondering if it is
>> possible to port it to Guile.
>>
>> It define a function to handle HTTP request in srv.arc(L48):
>>
>> (def handle-request-1 (s)
>>   --- pruned ---
>>             (with (th1 nil th2 nil)
>>               (= th1 (thread
>>                        (after (handle-request-thread i o ip)
>>                               (close i o)
>>                               (kill-thread th2))))
>>               (= th2 (thread
>>                        (sleep threadlife*)
>>                        (unless (dead th1)
>>                          (prn "srv thread took too long for " ip))
>>                        (break-thread th1)
>>                        (force-close i o))))))))
>>
>> It create two threads to handle a request, one do main stuff and anthor
>> one wait to kill first one if it takes too much time.
>>
>> Although I'm not quite sure, I think one reason to use 'kill-thread' and
>> 'break-thread' differently is to make sure that exception handler function
>> is fully executed. ('after' is implemented by  dynamic-wind).
>>
>> [1] http://ycombinator.com/arc/*arc3.1.tar*
>>
>>
>>> Thanks,
>>> Ludo’.
>>>
>>>
>>>
>>

[-- Attachment #2: Type: text/html, Size: 5507 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Ludovic Courtès]

Xin Wang <dram.wang@gmail.com> skribis:

> 2013/5/31 Ludovic Courtès <ludo@gnu.org>
>
>> Xin Wang <dram.wang@gmail.com> skribis:
>>
>> > In Guile, the equivalent of kill-thread is cancel-thread, and is there
>> any
>> > equivalent of break-thread?
>> >
>> > [1] http://docs.racket-lang.org/reference/breakhandler.html
>>
>> If I understand correctly, “breaks” are similar to Guile’s “asyncs”
>> (info "(guile) Asyncs").
>>
>> However, I don’t understand what you’re trying to achieve.  Could you
>> give another example of the behavior you’re after?
>>
>>
> I was reading source code of Arc language[1], and wondering if it is
> possible to port it to Guile.
>
> It define a function to handle HTTP request in srv.arc(L48):
>
> (def handle-request-1 (s)
>   --- pruned ---
>             (with (th1 nil th2 nil)
>               (= th1 (thread
>                        (after (handle-request-thread i o ip)
>                               (close i o)
>                               (kill-thread th2))))
>               (= th2 (thread
>                        (sleep threadlife*)
>                        (unless (dead th1)
>                          (prn "srv thread took too long for " ip))
>                        (break-thread th1)
>                        (force-close i o))))))))
>
> It create two threads to handle a request, one do main stuff and anthor one
> wait to kill first one if it takes too much time.

Here ‘break-thread’ in the first thread appears to be equivalent to
Guile’s ‘cancel-thread’.

> Although I'm not quite sure, I think one reason to use 'kill-thread' and
> 'break-thread' differently is to make sure that exception handler function
> is fully executed. ('after' is implemented by  dynamic-wind).

Hmm, I guess I still don’t understand what ‘break-thread’ is supposed to do.

Ludo’.

Re: The equivalent of racket's break-thread in guile?

[Xin Wang]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

2013/6/2 Ludovic Courtès <ludo@gnu.org>

> Xin Wang <dram.wang@gmail.com> skribis:
>
> > 2013/5/31 Ludovic Courtès <ludo@gnu.org>
> >
> >> Xin Wang <dram.wang@gmail.com> skribis:
> >>
> >> > In Guile, the equivalent of kill-thread is cancel-thread, and is there
> >> any
> >> > equivalent of break-thread?
> >> >
> >> > [1] http://docs.racket-lang.org/reference/breakhandler.html
> >>
> >> If I understand correctly, “breaks” are similar to Guile’s “asyncs”
> >> (info "(guile) Asyncs").
> >>
> >> However, I don’t understand what you’re trying to achieve.  Could you
> >> give another example of the behavior you’re after?
> >>
> >>
> > I was reading source code of Arc language[1], and wondering if it is
> > possible to port it to Guile.
> >
> > It define a function to handle HTTP request in srv.arc(L48):
> >
> > (def handle-request-1 (s)
> >   --- pruned ---
> >             (with (th1 nil th2 nil)
> >               (= th1 (thread
> >                        (after (handle-request-thread i o ip)
> >                               (close i o)
> >                               (kill-thread th2))))
> >               (= th2 (thread
> >                        (sleep threadlife*)
> >                        (unless (dead th1)
> >                          (prn "srv thread took too long for " ip))
> >                        (break-thread th1)
> >                        (force-close i o))))))))
> >
> > It create two threads to handle a request, one do main stuff and anthor
> one
> > wait to kill first one if it takes too much time.
>
> Here ‘break-thread’ in the first thread appears to be equivalent to
> Guile’s ‘cancel-thread’.
>

Do you mean 'kill-thread' in the first thread?


> > Although I'm not quite sure, I think one reason to use 'kill-thread' and
> > 'break-thread' differently is to make sure that exception handler
> function
> > is fully executed. ('after' is implemented by  dynamic-wind).
>
> Hmm, I guess I still don’t understand what ‘break-thread’ is supposed to
> do.
>
> Ludo’.
>

[-- Attachment #2: Type: text/html, Size: 3160 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Ludovic Courtès]

Xin Wang <dram.wang@gmail.com> skribis:

> 2013/6/2 Ludovic Courtès <ludo@gnu.org>
>
>> Xin Wang <dram.wang@gmail.com> skribis:
>>
>> > 2013/5/31 Ludovic Courtès <ludo@gnu.org>
>> >
>> >> Xin Wang <dram.wang@gmail.com> skribis:
>> >>
>> >> > In Guile, the equivalent of kill-thread is cancel-thread, and is there
>> >> any
>> >> > equivalent of break-thread?
>> >> >
>> >> > [1] http://docs.racket-lang.org/reference/breakhandler.html
>> >>
>> >> If I understand correctly, “breaks” are similar to Guile’s “asyncs”
>> >> (info "(guile) Asyncs").
>> >>
>> >> However, I don’t understand what you’re trying to achieve.  Could you
>> >> give another example of the behavior you’re after?
>> >>
>> >>
>> > I was reading source code of Arc language[1], and wondering if it is
>> > possible to port it to Guile.
>> >
>> > It define a function to handle HTTP request in srv.arc(L48):
>> >
>> > (def handle-request-1 (s)
>> >   --- pruned ---
>> >             (with (th1 nil th2 nil)
>> >               (= th1 (thread
>> >                        (after (handle-request-thread i o ip)
>> >                               (close i o)
>> >                               (kill-thread th2))))
>> >               (= th2 (thread
>> >                        (sleep threadlife*)
>> >                        (unless (dead th1)
>> >                          (prn "srv thread took too long for " ip))
>> >                        (break-thread th1)
>> >                        (force-close i o))))))))
>> >
>> > It create two threads to handle a request, one do main stuff and anthor
>> one
>> > wait to kill first one if it takes too much time.
>>
>> Here ‘break-thread’ in the first thread appears to be equivalent to
>> Guile’s ‘cancel-thread’.
>>
>
> Do you mean 'kill-thread' in the first thread?

Oh, yes, sorry for the confusion!

Ludo’.

Re: The equivalent of racket's break-thread in guile?

[Taylan Ulrich B.]

This is only partially relevant to the topic, but I'm very fond of the
run-loop/operation-queue based solution to the problem of ad-hoc
interleaved code execution in a certain thread, should the application
also otherwise lend itself to that generic architecture.

I have some spare time so let me elaborate, whatever it's worth.

There is no real interruption; a queued function on the run-loop will
execute atomically, but if the functions are kept at appropriate sizes
(don't "block the thread" for too long) it works well and is very easy
to use: asynchronous execution is started with e.g. `begin-thread'
wherever desired, and at any point some `begin-in-original-thread'
abstraction can be used to "switch back" to the original thread (by
inserting a function into the front of the execution queue),
"interrupting" its usual flow cleanly at the boundaries of a top-level
function-call in the run-loop (a queued operation), thus a primitive but
intuitive kind of synchronization is automatically achieved, making
further purpose-specific synchronization very easy with plain booleans
and such.

Cheap pseudo-code for a "set-up interface" function on a GUI run-loop:

(letrec
  ((request (uri-request image-uri))
   (cancel #f)
   (start-button
    (button #:label "Fetch image"
            #:action (lambda ()
                       (button-disable start-button)
                       (button-enable cancel-button)
                       (begin-thread
                         (let ((image-data (request-execute request)))
                           (begin-in-original-thread
                             (unless cancel
                               (button-disable cancel-button)
                               (display-image image-data))))))))
   (cancel-button
    (button #:label "Cancel"
            #:action (lambda ()
                       (request-cancel request)
                       (set! cancel #t)
                       (button-enable start-button)
                       (button-disable cancel-button)))))
  (display-button start-button)
  (display-button cancel-button)
  (button-disable cancel-button))

Since the URI request is executed in parallel, a race might happen with
regard to it finishing and being canceled.  On the other hand, access to
the `cancel' boolean is synchronous because all bodies of code that use
it are operations queued on the same run-loop (button actions are queued
on the run-loop).

Maybe I'm biased because the bulk of my day-to-day programming consists
of user-interface heavy applications which lend themselves very well to
a run-loop based architecture, and also I'm using a language that isn't
garbage-collected so cleaning up behind a ruthlessly interrupted/killed
thread can be a hassle; but I believe this method of parallelism and
synchronization to be significantly cleaner than manual/actual
interruption of threads.  I'm not aware of any Guile library that
implements run-loops and dispatch queues yet; perhaps I should try to
implement one.

Taylan

Re: The equivalent of racket's break-thread in guile?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

() taylanbayirli@gmail.com (Taylan Ulrich B.)
() Fri, 31 May 2013 13:20:00 +0200

   I'm not aware of any Guile library that implements run-loops and
   dispatch queues yet; perhaps I should try to implement one.

See also module ‘(ice-9 runq)’:
- (info "(guile) Run Queues")
- <http://www.gnuvola.org/software/guile/doc/Run-Queues.html>

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: The equivalent of racket's break-thread in guile?

[Taylan Ulrich B.]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> () taylanbayirli@gmail.com (Taylan Ulrich B.)
> () Fri, 31 May 2013 13:20:00 +0200
>
>    I'm not aware of any Guile library that implements run-loops and
>    dispatch queues yet; perhaps I should try to implement one.
>
> See also module ‘(ice-9 runq)’:
> - (info "(guile) Run Queues")
> - <http://www.gnuvola.org/software/guile/doc/Run-Queues.html>

Neat, that seems to be exactly it!  I see the module still exists, but
the documentation seems to have disappeared at some point.  (That
gnuvola page seems to document Guile 1.4??)

Re: The equivalent of racket's break-thread in guile?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

() taylanbayirli@gmail.com (Taylan Ulrich B.)
() Sat, 01 Jun 2013 08:46:21 +0200

   I see the module still exists, but the documentation seems to have
   disappeared at some point.  (That gnuvola page seems to document
   Guile 1.4??)

Maybe 2013 will see some motion of documentation from 1.4.x "forward"
to other Guile versions.  It all depends on Someone to find will/way.

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]