Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #39829 > unrolled thread

Minor problem with bye in Gforth

Back to article view | Back to comp.lang.forth

Contents

  Minor problem with bye in Gforth josv@planet.nl - 2015-06-18 07:57 -0700
    Re: Minor problem with bye in Gforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-18 22:21 +0200
      Re: Minor problem with bye in Gforth josv@planet.nl - 2015-06-18 15:17 -0700
        Re: Minor problem with bye in Gforth Mark Wills <markwills1970@gmail.com> - 2015-06-19 00:21 -0700
          Re: Minor problem with bye in Gforth josv@planet.nl - 2015-06-19 05:23 -0700
            Re: Minor problem with bye in Gforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-19 15:00 +0200
              Re: Minor problem with bye in Gforth josv@planet.nl - 2015-06-19 07:03 -0700

#39829 — Minor problem with bye in Gforth

According to the ANS standard approved: March 24, 1994
Bye should return control to the host operating system, if any.
When I run the following code in Gforth version 0.7.9.20150510
I stay in Gforth on my rPi.

include unix/pthread.fs

: test-bye ( -- )  700 ms bell bye ;
: start-bye-thread ( -- ) stacksize4 NewTask4 activate test-bye ;

start-bye-thread .s

\\ 
How can it be solved?
Jos

[toc] | [next] | [standalone]

#39838

josv@planet.nl wrote:

> According to the ANS standard approved: March 24, 1994
> Bye should return control to the host operating system, if any.
> When I run the following code in Gforth version 0.7.9.20150510
> I stay in Gforth on my rPi.
> 
> include unix/pthread.fs
> 
> : test-bye ( -- )  700 ms bell bye ;
> : start-bye-thread ( -- ) stacksize4 NewTask4 activate test-bye ;
> 
> start-bye-thread .s
> 
> \\
> How can it be solved?

BYE actually only returns from the Gforth engine; it's up to the starter of 
the engine, what to do.  In case of a thread, it just kills that thread.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#39846

On June 18th, 2015 22:21:52 UTC+2 Bernd Paysan wrote:
> j...@planet.nl wrote:
> 
> > According to the ANS standard approved: March 24, 1994
> > Bye should return control to the host operating system, if any.
> > When I run the following code in Gforth version 0.7.9.20150510
> > I stay in Gforth on my rPi.
> > 
> > include unix/pthread.fs
> > 
> > : test-bye ( -- )  700 ms bell bye ;
> > : start-bye-thread ( -- ) stacksize4 NewTask4 activate test-bye ;
> > 
> > start-bye-thread .s
> > 
> > \\
> > How can it be solved?
> 
> BYE actually only returns from the Gforth engine; it's up to the starter of 
> the engine, what to do.  In case of a thread, it just kills that thread.
> 
> -- 
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> http://bernd-paysan.de/

Hi Bernd,

Thank you for the explanation. 
I guess it means Gforth has no definition to leave Forth from a created thread in Gforth.

Jos

[toc] | [prev] | [next] | [standalone]

#39849

On Thursday, 18 June 2015 23:17:12 UTC+1, jo...@planet.nl  wrote:
> On June 18th, 2015 22:21:52 UTC+2 Bernd Paysan wrote:
> > j...@planet.nl wrote:
> > 
> > > According to the ANS standard approved: March 24, 1994
> > > Bye should return control to the host operating system, if any.
> > > When I run the following code in Gforth version 0.7.9.20150510
> > > I stay in Gforth on my rPi.
> > > 
> > > include unix/pthread.fs
> > > 
> > > : test-bye ( -- )  700 ms bell bye ;
> > > : start-bye-thread ( -- ) stacksize4 NewTask4 activate test-bye ;
> > > 
> > > start-bye-thread .s
> > > 
> > > \\
> > > How can it be solved?
> > 
> > BYE actually only returns from the Gforth engine; it's up to the starter of 
> > the engine, what to do.  In case of a thread, it just kills that thread.
> > 
> > -- 
> > Bernd Paysan
> > "If you want it done right, you have to do it yourself"
> > net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> > http://bernd-paysan.de/
> 
> Hi Bernd,
> 
> Thank you for the explanation. 
> I guess it means Gforth has no definition to leave Forth from a created thread in Gforth.
> 
> Jos

Sounds like you'll need to end your tasks in an orderly fashion, and then
have the top layer of your software execute BYE.

[toc] | [prev] | [next] | [standalone]

#39865

On 19 juni 2015 09:21:13 UTC+2 Mark Wills wrote:
> On Thursday, 18 June 2015 23:17:12 UTC+1, jo...@planet.nl  wrote:
> > On June 18th, 2015 22:21:52 UTC+2 Bernd Paysan wrote:
> > > j...@planet.nl wrote:
> > > 
> > > > According to the ANS standard approved: March 24, 1994
> > > > Bye should return control to the host operating system, if any.
> > > > When I run the following code in Gforth version 0.7.9.20150510
> > > > I stay in Gforth on my rPi.
> > > > 
> > > > include unix/pthread.fs
> > > > 
> > > > : test-bye ( -- )  700 ms bell bye ;
> > > > : start-bye-thread ( -- ) stacksize4 NewTask4 activate test-bye ;
> > > > 
> > > > start-bye-thread .s
> > > > 
> > > > \\
> > > > How can it be solved?
> > > 
> > > BYE actually only returns from the Gforth engine; it's up to the starter of 
> > > the engine, what to do.  In case of a thread, it just kills that thread.
> > > 
> > > -- 
> > > Bernd Paysan
> > > "If you want it done right, you have to do it yourself"
> > > net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> > > http://bernd-paysan.de/
> > 
> > Hi Bernd,
> > 
> > Thank you for the explanation. 
> > I guess it means Gforth has no definition to leave Forth from a created thread in Gforth.
> > 
> > Jos
> 
> Sounds like you'll need to end your tasks in an orderly fashion, and then
> have the top layer of your software execute BYE.

Hi Mark,

A bit hard when the console at the normal prompt.
Meanwhile I found a crude method:

include unix/pthread.fs

getpid constant pid-main-task

2Variable sh$  0. sh$ 2!  \ From script.fs
: sh-get ( addr u -- addr' u' )
     \G open command addr u, and read in the result
     sh$ free-mem-var
     r/o open-pipe throw dup >r slurp-fid
     r> close-pipe throw to $? 2dup sh$ 2! ;

: (.)   ( n -- addr len )   s>d tuck dabs <# #s rot sign #> ;

: bye    ( -- )
   s" kill -9 " pad place
   pid-main-task (.) pad +place pad pad count sh-get type ;

: test-bye ( -- ) 700 ms bell bye ;
: start-bye-thread ( -- ) stacksize4 NewTask4 activate test-bye ;

start-bye-thread .s
\\ Jos

[toc] | [prev] | [next] | [standalone]

#39869

josv@planet.nl wrote:
> Hi Mark,
> 
> A bit hard when the console at the normal prompt.
> Meanwhile I found a crude method:
> 
> include unix/pthread.fs
> 
> getpid constant pid-main-task
> 
> 2Variable sh$  0. sh$ 2!  \ From script.fs
> : sh-get ( addr u -- addr' u' )
>      \G open command addr u, and read in the result
>      sh$ free-mem-var
>      r/o open-pipe throw dup >r slurp-fid
>      r> close-pipe throw to $? 2dup sh$ 2! ;
> 
> : (.)   ( n -- addr len )   s>d tuck dabs <# #s rot sign #> ;
> 
> : bye    ( -- )
>    s" kill -9 " pad place
>    pid-main-task (.) pad +place pad pad count sh-get type ;
> 
> : test-bye ( -- ) 700 ms bell bye ;
> : start-bye-thread ( -- ) stacksize4 NewTask4 activate test-bye ;

IPC as is meant to be with unix/pthread.fs:

event: ->bye ( --- ) bye ;
up@ constant task0
: bye <event ->bye task0 event> ;

This won't work if the main task is busy with something and doesn't check 
the IPC stuff.

Other options: Send a signal to the main task using its pthread-id (this 
will only work with the current snapshot, because previously, the main 
pthread-id was left uninitialized; that's a bug):

pthread-id constant pthread-id0 \ id of task 0
: bye  pthread-id0 15 pthread_kill ;

This will send the SIGTERM signal.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#39873

On 19 juni 2015 15:00:01 UTC+2 Bernd Paysan wrote:
> j...@planet.nl wrote:
> > Hi Mark,
> > 
> > A bit hard when the console at the normal prompt.
> > Meanwhile I found a crude method:
> > 
> > include unix/pthread.fs
> > 
> > getpid constant pid-main-task
> > 
> > 2Variable sh$  0. sh$ 2!  \ From script.fs
> > : sh-get ( addr u -- addr' u' )
> >      \G open command addr u, and read in the result
> >      sh$ free-mem-var
> >      r/o open-pipe throw dup >r slurp-fid
> >      r> close-pipe throw to $? 2dup sh$ 2! ;
> > 
> > : (.)   ( n -- addr len )   s>d tuck dabs <# #s rot sign #> ;
> > 
> > : bye    ( -- )
> >    s" kill -9 " pad place
> >    pid-main-task (.) pad +place pad pad count sh-get type ;
> > 
> > : test-bye ( -- ) 700 ms bell bye ;
> > : start-bye-thread ( -- ) stacksize4 NewTask4 activate test-bye ;
> 
> IPC as is meant to be with unix/pthread.fs:
> 
> event: ->bye ( --- ) bye ;
> up@ constant task0
> : bye <event ->bye task0 event> ;
> 
> This won't work if the main task is busy with something and doesn't check 
> the IPC stuff.
> 
> Other options: Send a signal to the main task using its pthread-id (this 
> will only work with the current snapshot, because previously, the main 
> pthread-id was left uninitialized; that's a bug):
> 
> pthread-id constant pthread-id0 \ id of task 0
> : bye  pthread-id0 15 pthread_kill ;
> 
> This will send the SIGTERM signal.
> 
> -- 
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> http://bernd-paysan.de/

Hi Bernd,

Thank you. The event works perfect for me. 
Much better than my crude method.

Jos

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web