state-threads-users — State Threads users' list

Re: [ST-users] About st lib stack data preservation inMD_INIT_CONTEXT

[j. <jin...@qq...>]

Thank you so much. I have understood the st principles of stack operations.  


------------------ 原始邮件 ------------------
发件人: "Michael Abbott" <ya...@ya...>;
发送时间: 2016年12月13日(星期二) 21:21
收件人: "jingwei_5107" <jin...@qq...>;
抄送: "state-threads-users" <sta...@li...>;
主题: Re: [ST-users] About st lib stack data preservation inMD_INIT_CONTEXT



> In my understanding, the st should save the user-thread context pointers and the datas on the stack.

For all architectures except IA_64 that is accomplished by the MD_SETJMP.  IA_64 needs a little extra only because of its split stack.

Re: [ST-users] About st lib stack data preservation in MD_INIT_CONTEXT

[Michael A. <ya...@ya...>]

> In my understanding, the st should save the user-thread context pointers and the datas on the stack.

For all architectures except IA_64 that is accomplished by the MD_SETJMP.  IA_64 needs a little extra only because of its split stack.

[ST-users] About st lib stack data preservation in MD_INIT_CONTEXT

[j. <jin...@qq...>]

Hi experts:

I'm reading the st source codes, and meet a question. In my understanding, the st should save the user-thread context pointers and the datas on the stack. That is, the  MD_INIT_CONTEXT should be like this:


1: #define MD_INIT_CONTEXT(_thread, _sp, _bsp, _main)                       \
2:   ST_BEGIN_MACRO                                                         \
3:   if (MD_SETJMP((_thread)->context))                                     \
4:    _main();                                                             \
5:  memcpy((char *)(_bsp) - MD_STACK_PAD_SIZE,                             \
         (char *)(_thread)->context[0].__jmpbuf[17] - MD_STACK_PAD_SIZE, \
         MD_STACK_PAD_SIZE);                                             \
6:  (_thread)->context[0].__jmpbuf[0]  = (long) (_sp);                     \
7:  (_thread)->context[0].__jmpbuf[17] = (long) (_bsp);                    \
  ST_END_MACRO

memcpy does the copying of the stack frame data from stack to per st_thread.stack , while line 6-7 copies the context pointers. But I only see this definition of MD_INIT_CONTEXT under IA_64 architecture, while the common MD_INIT_CONTEXT does't have memcpy. It's like this:


#define MD_INIT_CONTEXT(_thread, _sp, _main) \
  ST_BEGIN_MACRO                             \
  if (MD_SETJMP((_thread)->context))         \
    _main();                                 \
  MD_GET_SP(_thread) = (long) (_sp);         \
  ST_END_MACRO



Do I have any misunderstanding about this question? st should save context pointers and the frame data on the stack, is it right? Do I miss something important somewhere?

Re: [ST-users] _st_epoll_dispatch firing too often

[CN <cu...@ya...>]

This was on two different Linux boxes, one 2.6.25.11-97.fc9.x86_64, and another 2.6.35.14-96.fc14.i686.  No VMs.
I've just tried on another box running 3.2.6-3.fc16.x86_64, and that seems to work correctly just like yours.
Perhaps it's just specific Linux kernels. I don't think anyone's got the patience to sit there and test which kernels don't play well.


----- Original Message -----
From: Michael Abbott <ya...@ya...>
To: CN <cu...@ya...>
Cc: "sta...@li..." <sta...@li...>
Sent: Wednesday, 5 December 2012 5:11 AM
Subject: Re: [ST-users] _st_epoll_dispatch firing too often

> _st_epoll_dispatch seems to fire too often when the sleepq is not empty.

On what OS?  Your test program works fine for me on Linux and OS X:

1354644462832661 MAIN diff = 1002671
1354644463832701 MAIN diff = 999990
1354644464832747 MAIN diff = 1000027
1354644465832793 MAIN diff = 1000026
1354644466832836 MAIN diff = 1000020

(I made it print the current st_utime() instead of the pointers, in the first column.)
The "ST diff" messages never even appear.

Are you running in a virtual machine?  VMs have been known to fire timers at unexpected times. 

Re: [ST-users] _st_epoll_dispatch firing too often

[Michael A. <ya...@ya...>]

> _st_epoll_dispatch seems to fire too often when the sleepq is not empty.

On what OS?  Your test program works fine for me on Linux and OS X:

1354644462832661 MAIN diff = 1002671
1354644463832701 MAIN diff = 999990
1354644464832747 MAIN diff = 1000027
1354644465832793 MAIN diff = 1000026
1354644466832836 MAIN diff = 1000020

(I made it print the current st_utime() instead of the pointers, in the first column.)
The "ST diff" messages never even appear.

Are you running in a virtual machine?  VMs have been known to fire timers at unexpected times.

[ST-users] _st_epoll_dispatch firing too often

[CN <cu...@ya...>]

_st_epoll_dispatch seems to fire too often when the sleepq is not empty. 
My guess is that it has something to do with granularity.
Here's some basic code to reproduce:

#include <stdio.h>
#include "st.h"
int main(int argc, char *argv[])

{
    st_utime_t t1, t2;
    st_set_eventsys(ST_EVENTSYS_ALT);
    st_init();
    for (;;) {

        t1 = st_utime();
        st_sleep(1);
        t2 = st_utime();
        fprintf(stderr, "%p MAIN diff = %llu\n", st_thread_self(), t2 - t1);
    }
    return 0;

}


And add some logging to event.c @ line 1244.
ie.
1243:  timeout = (int) (min_timeout / 1000);
1244:  if (timeout == 0 && _ST_SLEEPQ->due > _ST_LAST_CLOCK)
1245:      fprintf(stderr, "%p ST   diff=%llu\n", _ST_SLEEPQ, _ST_SLEEPQ->due - _ST_LAST_CLOCK);
1245: }

You'll also need "#include <stdio.h>" .


If you run the test, you'll see something like:
0x805f068 MAIN diff = 999992
0x805f068 ST   diff=241
0x805f068 ST   diff=222
0x805f068 ST   diff=210
0x805f068 ST   diff=199
0x805f068 ST   diff=188
0x805f068 ST   diff=177
0x805f068 ST   diff=166
0x805f068 ST   diff=155
0x805f068 ST   diff=144
0x805f068 ST   diff=133
0x805f068 ST   diff=122
0x805f068 ST   diff=111
0x805f068 ST   diff=100
0x805f068 ST   diff=89
0x805f068 ST   diff=78
0x805f068 ST   diff=66
0x805f068 ST   diff=55
0x805f068 ST   diff=44
0x805f068 ST   diff=33
0x805f068 ST   diff=23
0x805f068 ST   diff=12
0x805f068 ST   diff=1
0x805f068 MAIN diff = 1000000



The unnecessary firing gets worse when the sleepq gets longer.
My "fix" for this is to put a limit on the timeout, like so:
if (_ST_SLEEPQ->due <= _ST_LAST_CLOCK) {
    timeout = 0;
} else {
    min_timeout = _ST_SLEEPQ->due - _ST_LAST_CLOCK;
    if (min_timeout < 300) /* magic number 300 seems to work well */
        timeout = 1;
    else
        timeout = (int) (min_timeout / 1000);
}

Is this a bug or am I using st-threads incorrectly?
If it's a bug, is there a better way to fix it without using magic numbers?


Regards,
C.

[ST-users] Why do the st_recvmsg()/st_sendmsg() docs refer to UDP sockets?

[Mark D. <x2...@si...>]

I'm curious as to why the docs constain st_sendmsg() and st_recvmsg()
to UDP?

To quote from
http://state-threads.sourceforge.net/docs/reference.html#sendmsg "A
file descriptor object identifier (see st_netfd_t) representing a UDP
socket"

But I don't see anything in the st code that requires this constraint,
furthermore I've long used st_sendmsg() and st_recvmsg() on TCP
sockets as it's the only way to do an inter-process fdpass with this
sort of code:

  control->cmsg_level = SOL_SOCKET;
  control->cmsg_type = SCM_RIGHTS;

My guess is that it's just an historical accident in the docs that
might have been cloned from st_sendto()/st_recvfrom() function - which
are constrained to UDP.


Mark.

[ST-users] STL and weird valgrind warnings

[Hamdi H. <ha...@gm...>]

Hi guys,

Valgrind outputs very weird warnings. Please check the log file I've
attached. The properties of the threads are correct when you print them and
they work as expected. There is no stack smashing/overflowing.

Tests are made with the  latest version of STL.

Regards,
H. Hamdi

Re: [ST-users] Terminate threads

[Michael A. <ya...@ya...>]

> I have a process A that creates a thread to do logging, then forks
> another process B.

Programs using State Threads should fork before creating threads.  One
idiom is to have a master process which forks and uses no threads
itself, while the child processes manage their own threads.

> How do I get B to terminate any existing inherited threads such as the
> logging thread.

State Threads does not provide a way to "kill" a thread.  Instead each
thread can check a flag in its main loop to see whether it should exit.
The flag can be a global variable or a pointer passed as the arg to
st_thread_create().  For threads which are blocking,
st_thread_interrupt() wakes them up but does not kill them.

Your "IAmSpartacus" example is close but I'd code it this way:

int run_logger = 1;
st_thread_t logger_thread = st_thread_create(..., &run_logger, ...);
...
if (fork() == 0) {
  run_logger = 0;
  st_thread_interrupt(logger_thread);
}
...
static void *flush_acclog_buffer(int *keep_running)
{
  while (*keep_running) {
    if (st_sleep(ACCLOG_FLUSH_INTERVAL) == 0)
      logbuf_flush();
  }
  return NULL;
}

[ST-users] Terminate threads

[Cuong N. <cu...@ya...>]

Hi All,

I have a process A that creates a thread to do logging, then forks another process B.

How do I get B to terminate any existing inherited threads such as the logging thread.

Using the "server.c" as an example, where flush_acclog_buffer()  is running in a thread, is there something cleaner than than:

int IAmSpartacus = 1;

...
IAmSpartacus = 0;
if (fork() > 0) {
   IAmSpartacus = 1;
}
...


static void *flush_acclog_buffer(void *arg)
{
    for ( ; IAmSpartacus == 1 ; ) {
st_sleep(ACCLOG_FLUSH_INTERVAL);
logbuf_flush();
    }
    return NULL;

}

[ST-users] Question in _st_stack_new

[Alfred Z. <alf...@gm...>]

Hi Dear ST Developers and Users,

I am reading ST 1.9's source has encounter a piece of code that I can't
figure out for a week.

In stk.c,

in the body of the function

_st_stack_t *_st_stack_new(int stack_size)

I understand this function is to allocate memory space for the stack. And
update the stack records.

There is this piece

for (qp = _st_free_stacks.next; qp != &_st_free_stacks; qp = qp->next)
 //when is _st_free_stack.next!= qp?
{
ts = _ST_THREAD_STACK_PTR(qp);
/*
Here I lookup what _ST_THREAD_STACK_PTR does and found

#define offsetof(type, identifier) (/***/ (size_t)&(/**/( (type
*)0)->identifier/**/) /***/)
It looks like this macro finds a instance of "_st_stack_t"'s element "links"
's address and cast it into size_t type?
I am totally confused about this! Cast address 0 points to _st_stack_t type
variable, but the space is never allocated yet. How does this work?


#define _ST_THREAD_STACK_PTR(_qp)   \
    (/**/ (_st_stack_t *)(/***/ (char*)(_qp) - offsetof(_st_stack_t, links)
/***/) /**/)
cast _st_clist_t type variable _qp to into byte point and minus this
"offset" that I don't understand. Confused again.

_qp is of _st_clist_t type,

*/
if (ts->stk_size >= stack_size)
{
/* Found a stack that is big enough */
ST_REMOVE_LINK(&ts->links);
_st_num_free_stacks--;
ts->links.next = NULL;
ts->links.prev = NULL;
return ts;
}
}

What does this for loop do?
I notice at the beginning of stk.c,
_st_clist_t _st_free_stacks = ST_INIT_STATIC_CLIST(&_st_free_stacks);
This set _st_free stack 's next and prev pointer pointing to itself.
Inside _st_stack_new(...), I don't see _st_free_stacks is changed.

I guess _st_list_t type is a link list. However, it has only next and prev
pointers. Where is the data?

Thanks a lot for any suggestions!
Alfred

Re: [ST-users] problem of stack size in st_thread_create()

[Alfred Z. <alf...@gm...>]

Oh my god!

+ _ST_PAGE_SIZE - 1

if stk_size is just x times of the _ST_PAGE_SIZE, the integer division will
return exactly x b/c of the -1.

if stk_size is smaller than x times of _ST_PAGE_SIZE, the integer division
will return exactly x, and ignore the remaining >x but <x+1

That is smart!
If the purpose is in the comment or docs will be better to understand

Thanks a lot, John!

Alfred

On Wed, Aug 10, 2011 at 1:11 PM, John Newton <jn...@gm...> wrote:

> The line you are asking about is a "round up" to the next page size
> calculation.
>
> For example, if getpagesize() returns 4096, and the "stk_size" parameter is
> 10,000 it would round up to the next even page size. (the division is doing
> integer math)
>
> Hope this helps!
>
> On Wed, Aug 10, 2011 at 9:06 AM, Alfred Zhong <alf...@gm...>wrote:
>
>> Hi,
>> I am new to state thread library and am reading the source code of ST to
>> study implementation of threading.
>>
>> in the st_thread_create() function
>>
>> there is this code piece
>>
>> if (stk_size == 0)
>>     stk_size = ST_DEFAULT_STACK_SIZE;  // I know this is to set the stack
>> size to a default size, if the input size is 0
>>   stk_size = ((stk_size + _ST_PAGE_SIZE - 1) / _ST_PAGE_SIZE) *
>> _ST_PAGE_SIZE; //what does this mean?
>>
>> Look like it equals (stk_size + ST_PAGE_SIZE -1) unless the previous
>> division gives 0.
>>
>> I am totally confused and can't find the answer in the code or the docs,
>> please help!
>>
>> Thanks a lot!
>> Alfred
>>
>>
>> ------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>>
>> _______________________________________________
>> State-threads-users mailing list
>> Sta...@li...
>> https://lists.sourceforge.net/lists/listinfo/state-threads-users
>>
>>
>

Re: [ST-users] problem of stack size in st_thread_create()

[John N. <jn...@gm...>]

The line you are asking about is a "round up" to the next page size
calculation.

For example, if getpagesize() returns 4096, and the "stk_size" parameter is
10,000 it would round up to the next even page size. (the division is doing
integer math)

Hope this helps!

On Wed, Aug 10, 2011 at 9:06 AM, Alfred Zhong <alf...@gm...> wrote:

> Hi,
> I am new to state thread library and am reading the source code of ST to
> study implementation of threading.
>
> in the st_thread_create() function
>
> there is this code piece
>
> if (stk_size == 0)
>     stk_size = ST_DEFAULT_STACK_SIZE;  // I know this is to set the stack
> size to a default size, if the input size is 0
>   stk_size = ((stk_size + _ST_PAGE_SIZE - 1) / _ST_PAGE_SIZE) *
> _ST_PAGE_SIZE; //what does this mean?
>
> Look like it equals (stk_size + ST_PAGE_SIZE -1) unless the previous
> division gives 0.
>
> I am totally confused and can't find the answer in the code or the docs,
> please help!
>
> Thanks a lot!
> Alfred
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>
> _______________________________________________
> State-threads-users mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/state-threads-users
>
>

[ST-users] problem of stack size in st_thread_create()

[Alfred Z. <alf...@gm...>]

Hi,
I am new to state thread library and am reading the source code of ST to
study implementation of threading.

in the st_thread_create() function

there is this code piece

if (stk_size == 0)
    stk_size = ST_DEFAULT_STACK_SIZE;  // I know this is to set the stack
size to a default size, if the input size is 0
  stk_size = ((stk_size + _ST_PAGE_SIZE - 1) / _ST_PAGE_SIZE) *
_ST_PAGE_SIZE; //what does this mean?

Look like it equals (stk_size + ST_PAGE_SIZE -1) unless the previous
division gives 0.

I am totally confused and can't find the answer in the code or the docs,
please help!

Thanks a lot!
Alfred

Re: [ST-users] Multiple asynchronous operations

[Michael A. <ya...@ya...>]

> that only applies to I/O, as opposed to asynchronous operations in
> general, such as mutex locking, sleeping, or any other user-defined
> asynchronous operation.

Yes and no.  Yes, in that st_poll() does directly support waiting for
I/O only.  No, because other async operations can map to I/O by reading
and writing a pipe or socketpair.  For instance, user-defined lock
functions could write something to a pipe whenever they lock or unlock a
lock, and another thread could poll and read from the pipe to learn when
such actions happen.  This is how we recommend translating UNIX signals
to I/O operations too; see
        http://state-threads.sourceforge.net/docs/notes.html

Re: [ST-users] Multiple asynchronous operations

[Yang Z. <yan...@gm...>]

On Wed, Sep 16, 2009 at 11:54 AM, Michael Abbott <ya...@ya...> wrote:
>> What would be the easiest way to be able to wait on multiple
>> asynchronous operations without having to create a thread per
>> operation?
>
> st_poll()

Correct me if I'm wrong, but that only applies to I/O, as opposed to
asynchronous operations in general, such as mutex locking, sleeping
(though I know there's a timeout parameter already for this), or any
other user-defined asynchronous operation.
-- 
Yang Zhang
http://www.mit.edu/~y_z/

Re: [ST-users] Multiple asynchronous operations

[Michael A. <ya...@ya...>]

> What would be the easiest way to be able to wait on multiple
> asynchronous operations without having to create a thread per
> operation?

st_poll()

[ST-users] Multiple asynchronous operations

[Yang Z. <yan...@gm...>]

What would be the easiest way to be able to wait on multiple
asynchronous operations without having to create a thread per
operation? I'm trying to write my own primitives for this, but I'm not
sure it's possible without modifying ST itself. Any thoughts would be
greatly appreciated.
-- 
Yang Zhang
http://www.mit.edu/~y_z/

Re: [ST-users] System threads (pthreads)

[Yang Z. <yan...@gm...>]

Mike Abbott wrote:
>> I'm interested in as many details as you can spare.
> 
> On 2002-11-26 Gene wrote this:
> | I did some digging in the linuxthreads source.  I think the
> | culprit is in the inlined function thread_self() which is called
> | by __errno_location().  That function relies on stack pointer to
> | get pthread's identity.  The "stack pointer" is just an address
> | of a local variable:
> | 
> | #define CURRENT_STACK_FRAME  ({ char __csf; &__csf; })
> | char *sp = CURRENT_STACK_FRAME;
> | 
> | In other words, libpthread assumes that there is only one stack
> | per each pthread and thus thread id can be inferred from the
> | stack pointer.  If there are stack segments other than created
> | by libpthread, thread_self() may return bogus thread id.
> | 
> | The bottom line, I guess, is that current pthreads implementation
> | cannot be mixed with any other thread library.
> | 
> | --Gene
> 
> I remember discussing other issues, in particular a collision on some
> special memory location, but I don't recall the details.
> 
> Interop between ST and pthreads comes up repeatedly though, so if you
> find a fix we'd love to receive it.
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> State-threads-users mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/state-threads-users

Is ST really incompatible with OS threads?  This simple test works, but 
I've also been writing a real application where I just started mixing 
pthreads and state-threads, and it seems there are no problems so far, 
but I'm afraid I'm missing something.  Is there an example of something 
that breaks?  (Also, if ST really doesn't work--how does Pth manage to 
coexist with pthreads?)

// Demonstrates ST compatibility with OS threads.

#include <iostream>
#include <pthread.h>
#include <st.h>
#include <unistd.h>

using namespace std;

void *f(void *p) {
   cout << "hello" << endl;
   st_sleep(1);
   cout << "goodbye" << endl;
   return 0;
}

void *F(void *p) {
   cout << "HELLO" << endl;
   sleep(1);
   cout << "GOODBYE" << endl;
   return 0;
}

int main() {
   st_init();
   st_thread_t t1 = st_thread_create(f, 0, 1, 0);
   st_thread_t t2 = st_thread_create(f, 0, 1, 0);

   pthread_t T;
   pthread_create(&T, NULL, F, 0);

   st_thread_join(t1, 0);
   st_thread_join(t2, 0);

   pthread_join(T, 0);

   return 0;
}
-- 
Yang Zhang
http://www.mit.edu/~y_z/

[ST-users] Profiling

[Yang Z. <yan...@gm...>]

Does anybody have experience profiling ST programs?  Any advice on how
to do this?

I'm currently trying to profile this simple C++ app:

http://assorted.svn.sourceforge.net/viewvc/assorted/ydb/trunk/src/main.lzz.clamp?revision=1130&view=markup

(Higher-level info about this program can be found at
http://assorted.sf.net/ydb/.)

With gprof, I obtain strange results.  They don't appear to be garbage,
but otherwise I'm not sure whether (or how) to trust the results:

- Many things are shown as taking up 100% of the time.  How exactly does
gprof work (with ST)?  Does gprof somehow understand the different ST
threads as different threads, and thus be able to give a full 100% to
each thread?  Because if not, I'd expect each thread to take up <100%
(but add up to 100%).  Does this even happen with OS threads?

- Certain connections aren't being made, such as the one between
swallow and issue_txns.

See some [gprof output] from a run of this program (running as a 
leader), along with [the visualization] produced using [gprof2dot]. 
(BTW, [xdot] is a good dot viewer.)

[gprof output]: http://www.mit.edu/~y_z/st-prof/gprof.bz2
[the visualization]: http://www.mit.edu/~y_z/st-prof/dot.pdf
[gprof2dot]: http://code.google.com/p/jrfonseca/wiki/Gprof2Dot
[xdot]: http://code.google.com/p/jrfonseca/wiki/XDot

Aside: has anybody tried using google-perftools with ST?
-- 
Yang Zhang
http://www.mit.edu/~y_z/

[ST-users] Profiling

[Yang Z. <yan...@gm...>]

Does anybody have experience profiling ST programs?  Any advice on how 
to do this?

I'm currently trying to profile this simple C++ app:

http://assorted.svn.sourceforge.net/viewvc/assorted/ydb/trunk/src/main.lzz.clamp?revision=1130&view=markup

(Higher-level info about this program can be found at 
http://assorted.sf.net/ydb/.)

With gprof, I obtain strange results.  They don't appear to be garbage, 
but otherwise I'm not sure whether (or how) to trust the results:

- many things are shown as taking up 100% of the time.  How exactly does 
gprof work (with ST)?  Does gprof somehow understand the different ST 
threads as different threads, and thus be able to give a full 100% to 
each thread?  Because if not, I'd expect each thread to take up <100% 
(but add up to 100%).  Does this even happen with OS threads?

- certain connections aren't being made, such as the one between 
handle_responses and swallow and issue_txns.

Aside: has anybody tried using google-perftools with this?

I have attached my gprof output.  I recommend visualizing it with the 
following tools:

http://code.google.com/p/jrfonseca/wiki/Gprof2Dot
http://code.google.com/p/jrfonseca/wiki/XDot
-- 
Yang Zhang
http://www.mit.edu/~y_z/

Re: [ST-users] Help applying print_stk patch

[Yang Z. <yan...@gm...>]

Yang Zhang wrote:
> Mike Abbott wrote:
>>> $ CPATH=/tmp/st-1.8/LINUX_2.6.27-7-generic_DBG/ 
>>> LIBRARY_PATH=/tmp/st-1.8/LINUX_2.6.27-7-generic_DBG/ gcc stbt.c -lst
>>> /tmp/ccoL3i05.o: In function `h':
>>> stbt.c:(.text+0x2e): undefined reference to `_st_print_thread_stacks'
>>> collect2: ld returned 1 exit status
>>
>> I get exactly the same error when I use the wrong path
>> (the wrong LINUX_whatever_DBG), but when I use the right path the gcc
>> command works.  Then when I run
>> "LD_LIBRARY_PATH=/tmp/st-1.8/LINUX_whatever_DBG ./a.out" it runs fine.
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great 
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> State-threads-users mailing list
>> Sta...@li...
>> https://lists.sourceforge.net/lists/listinfo/state-threads-users
> 
> Whoops.  Turned out I had two libst.a's on my system, and the other one 
> was getting in the way.

Now I can build and run the program:

#define DEBUG
#include <st.h>
void h(int s) {
   _st_print_thread_stacks(0);
}
void *f(void *p) {
   st_sleep(1);
   h(0);
   return NULL;
}
int main() {
   st_init();
   st_thread_t ts[3];
   int i;
   for (i = 0; i < 3; i++)
     ts[i] = st_thread_create(&f, NULL, 1, 0);
   // h(0); // I get a seg fault here if I uncomment this.
   for (i = 0; i < 3; i++)
     st_thread_join(ts[i], NULL);
   return 0;
}

but it prints out nothing (except for a correct thread count):

5 thread(s) with this backtrace:


5 thread(s) with this backtrace:


5 thread(s) with this backtrace:


-- 
Yang Zhang
http://www.mit.edu/~y_z/

Re: [ST-users] Waiting on multiple blocking events

[Yang Z. <yan...@gm...>]

Yang Zhang wrote:
> Mike Abbott wrote:
>>> Is there a way to "compose" together multiple blocking operations? 
>>
>> Sounds interesting, kinda like what kqueue()/kevent() do:  one-stop
>> event processing.  "Block this thread until one of this laundry list of
>> disparate events fires."  Do you have a prototype implementation you'd
>> like to contribute to the project, or wrappers you'd contribute to its
>> "extensions" library?
> 
> I have a poor man's implementation of "cleanly interruptible points." 
> This involves primitives called "hubs" (sets of threads) that threads 
> may join and other threads may signal.  It's similar to a condition 
> variable, but signaling results in interrupting the thread from its 
> current blocking operation.
> 
>   {
>     st_intr intr(hub);
>     int ret = st_read_fully(...);
>     if (ret == EINT) ...
>     ...
>   }
> 
> This turned out to be suitable enough for my purposes.  The code is all 
> available in my little header of ST tools:
> 
> http://assorted.svn.sf.net/viewvc/assorted/cpp-commons/trunk/src/commons/st/st.h?revision=1077&view=markup 
> 
> 
> I thought about my more general suggestion some more.  You can implement 
> any() atop ST by starting a thread for each blocking operation involved 
> in the any(), wrapping them in functions that - on finishing - interrupt 
> the other threads (using something similar to the above mechanism, on a 
> hub created locally by the any() call), informing them that they're the 
> losers (so that they may properly react/clean up), and also notifying 
> the parent thread of its own success and return value.

Forgot to add: such an implementation would be much more expensive than 
it needs to be, since it's actually creating a separate thread per 
blocking operation, when in fact you shouldn't really need to do this if 
you're willing to modify ST to explicitly support such operation.

> 
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great 
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> State-threads-users mailing list
>> Sta...@li...
>> https://lists.sourceforge.net/lists/listinfo/state-threads-users
> 
> 


-- 
Yang Zhang
http://www.mit.edu/~y_z/

Re: [ST-users] Waiting on multiple blocking events

[Yang Z. <yan...@gm...>]

Mike Abbott wrote:
>> Is there a way to "compose" together multiple blocking operations? 
> 
> Sounds interesting, kinda like what kqueue()/kevent() do:  one-stop
> event processing.  "Block this thread until one of this laundry list of
> disparate events fires."  Do you have a prototype implementation you'd
> like to contribute to the project, or wrappers you'd contribute to its
> "extensions" library?

I have a poor man's implementation of "cleanly interruptible points." 
This involves primitives called "hubs" (sets of threads) that threads 
may join and other threads may signal.  It's similar to a condition 
variable, but signaling results in interrupting the thread from its 
current blocking operation.

   {
     st_intr intr(hub);
     int ret = st_read_fully(...);
     if (ret == EINT) ...
     ...
   }

This turned out to be suitable enough for my purposes.  The code is all 
available in my little header of ST tools:

http://assorted.svn.sf.net/viewvc/assorted/cpp-commons/trunk/src/commons/st/st.h?revision=1077&view=markup

I thought about my more general suggestion some more.  You can implement 
any() atop ST by starting a thread for each blocking operation involved 
in the any(), wrapping them in functions that - on finishing - interrupt 
the other threads (using something similar to the above mechanism, on a 
hub created locally by the any() call), informing them that they're the 
losers (so that they may properly react/clean up), and also notifying 
the parent thread of its own success and return value.

> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> State-threads-users mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/state-threads-users


-- 
Yang Zhang
http://www.mit.edu/~y_z/

Re: [ST-users] C++ stack unwinding

[Yang Z. <yan...@gm...>]

Mike Abbott wrote:
>> I'd like stack unwinding to take place in *all* spawned threads
> 
> As you discovered, ST has no knowledge of C++ exceptions.
> 
> However, I think you may be relying on platform-specific behavior.  My
> understanding of uncaught exceptions is that they result in terminate()
> being called, which defaults to abort(), which means no destructors are
> called for any objects.  If you remove all the ST functions from your
> test program and simply throw an uncaught exception:
> 
> [...]
> int main() {
>    cleanup c;
> //   st_init();
> //   st_thread_t t = st_thread_create(&f, (void*)"abc", 1, 0);
> //   st_thread_join(t, NULL);
>    f(NULL);
>    return 0;
> }
> 
> then c's destructor is not called either.  This matches what my copy of
> Stroustrup says.  Does something different happen on your system?

Interesting!  The same also happens for me.  I always thought that 
destructors/RAII was the C++ way to do `finally`, but I suppose it comes 
with a caveat about the top-level composition of the program properly 
catching all exceptions.  Surprisingly, I can't find much other 
discussion of this on the web.

> 
> On the other hand, if you were trying to have thread A *catch* an
> exception thrown by thread B, then I could understand your desire to
> have stack unwinding work properly and have object c's destructor
> called.  But ST does not support propagating C++ exceptions across
> threads.  ST does work just fine with C++ -- I have done so myself --
> just not when it comes to exceptions crossing threads.

After thinking about this some more, I'm not sure I can do this at all. 
  Even if I used RTTI to determine the dynamic type of the exception, 
catches operate on the static type of the exception.

> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> State-threads-users mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/state-threads-users


-- 
Yang Zhang
http://www.mit.edu/~y_z/