state-threads-devel — State Threads developers' list

[ST-devel] autoconf, automake, & libtool

[David S. <sy...@gm...>]

List,

Is there any active efforts to enable the use of autoconf, automake, and
libtool when compiling state threads? If there are no active efforts, would
the group be open to the idea using these tools? If there are technical
reasons for not wishing to pursue the use of these tools I would be
interested to hear them for educational purposes.

In a superficial search of the mailing list, I saw that Wesley Terstra
started work on autoconf scripts for state threads, but the last reference =
I
see to this work was posted in 2002 around release 1.3.

Thanks
David Syzdek

--
You don't stop laughing because you grow old. You grow old because you stop
laughing.
-- Michael Pritchard

[ST-devel] Re: server structure

[<ge...@co...>]

> - pls comment on the structure below and/or recommend something as the
> server example is somewhat different - i.e. can i just accept &
> read "ahead" or should i st_poll() across all connections?

The structure makes sense. You don't need to poll across all connections since
you have one thread per connection.

> - if one st thread reads & then sends on to a number of connections, if
> one of these is slow, then i presume this st_thread will block,
> preventing any further writes from happening until it has finished - how
> can i deal with this?

There are several ways to deal with this. In the simplest case when your
message sizes are not too big, you can just set socket output buffer size
to a large value (setsockopt(SO_SNDBUF)), e.g. 1MB. Then just use
non-blocking writes (not st_write()s) directly.  It'll return an error when
socket output buffer is full (at that point you may want to discard outgoing
message).

> - how can i benefit from additional processors when i can only listen to
> one port in a single physical thread?

You fork processes after you create listening socket. Also see
http://state-threads.sourceforge.net/docs/faq.html#cpus

> - how should a client close be properly managed?

reading thread should take care of a client close (st_read() will return 0, at this
point you should close connection and remove it from your list).

Hope it helps,
Gene

[ST-devel] server structure

[terry j. <ter...@fa...>]

thank you for the state threads project - i would appreciate some advice
on its use as i am interested in developing a
publish & subcribe messaging server with ST - i.e. lots of open
connections sending & receiving...

- does this make sense?
- pls comment on the structure below and/or recommend something as the
server example is somewhat different - i.e. can i just accept &
read "ahead" or should i st_poll() across all connections?
- if one st thread reads & then sends on to a number of connections, if
one of these is slow, then i presume this st_thread will block,
preventing
any further writes from happening until it has finished - how can i deal
with this?
- how can i benefit from additional processors when i can only listen to
one port in a single physical thread?
- how should a client close be properly managed?

basic structure...
- listens, then accepts in a loop, starting a new st thread for each
connection, maintaining a list of connections
- each st thread reads, processes & then goes through the list,
st_writing as appropriate

thanks
terry
-- 
  terry johnston
  ter...@fa...

[ST-devel] ST 1.5.2

[Mike A. <mj...@co...>]

Experimental version 1.5.2 of the State Threads Library is now
available.  It adds support for more platforms and blesses the
callback-on-context-switch feature.  See the included README
file for details.  Barring a major error, this will become the
1.6 release.

Download it from:  http://state-threads.sourceforge.net/

As always, your contributions and comments are welcome.
--
Mike Abbott    ma...@us...
State Threads Project co-administrator

Re: [ST-devel] [PATCH] support FreeBSD amd64

[Anton B. <to...@Fr...>]

On Thu, Aug 11, 2005 at 05:22:25AM -0700, Alfred Perlstein wrote:
> Can you commit it to the port?

Once the freeze is over, sure.  (But also see PR 84791)

> * Anton Berezin <to...@Fr...> [050811 03:24] wrote:
> > --- md.h.orig	Thu Aug 11 11:15:00 2005
> > +++ md.h	Thu Aug 11 11:33:23 2005
> > @@ -154,6 +154,8 @@
> >  #define MD_JB_SP   2
> >  #elif defined(__alpha__)
> >  #define MD_JB_SP  34
> > +#elif defined(__amd64__)
> > +#define MD_JB_SP  2
> >  #else
> >  #error Unknown CPU architecture
> >  #endif
> > 
> > Tested and works.

\Anton.
-- 
The moronity of the universe is a monotonically increasing function. --
Jarkko Hietaniemi

Re: [ST-devel] [PATCH] support FreeBSD amd64

[Alfred P. <al...@fr...>]

Can you commit it to the port?

* Anton Berezin <to...@Fr...> [050811 03:24] wrote:
> --- md.h.orig	Thu Aug 11 11:15:00 2005
> +++ md.h	Thu Aug 11 11:33:23 2005
> @@ -154,6 +154,8 @@
>  #define MD_JB_SP   2
>  #elif defined(__alpha__)
>  #define MD_JB_SP  34
> +#elif defined(__amd64__)
> +#define MD_JB_SP  2
>  #else
>  #error Unknown CPU architecture
>  #endif
> 
> Tested and works.
> 
> -- 
> The moronity of the universe is a monotonically increasing function. --
> Jarkko Hietaniemi
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> State-threads-devel mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/state-threads-devel

-- 
- Alfred Perlstein

[ST-devel] [PATCH] support FreeBSD amd64

[Anton B. <to...@Fr...>]

--- md.h.orig	Thu Aug 11 11:15:00 2005
+++ md.h	Thu Aug 11 11:33:23 2005
@@ -154,6 +154,8 @@
 #define MD_JB_SP   2
 #elif defined(__alpha__)
 #define MD_JB_SP  34
+#elif defined(__amd64__)
+#define MD_JB_SP  2
 #else
 #error Unknown CPU architecture
 #endif

Tested and works.

-- 
The moronity of the universe is a monotonically increasing function. --
Jarkko Hietaniemi

Re: [ST-devel] AMD64 FreeBSD port works 99.9% ...

[Mike A. <mj...@co...>]

> #elif defined(__amd64__)
> #define MD_JB_SP   2
> #else
> 
> This is the only change I have made to st to get my app to work 99.9% of the 
> time. What doesn't work is *printf() calls with a double arguement.

What was the resolution of this issue with ST on FreeBSD/AMD64?  I'd
like to include this in the next ST release.

[ST-devel] Patch: printing stack of all threads

[Michael Abd-El-M. <mab...@cm...>]

Hello,

This is a patch that enables programmatically dumping the stack of  
every thread.  This has been useful in debugging deadlocks, etc...   
Our usage model is that the SIGUSR2 handler calls the new  
_st_print_thread_stacks function, which dumps the stack for all  
threads.  A convenient feature is that for thread stacks that are the  
same (which is common for application with a lot of worker threads  
waiting for work), only one stack trace is printed, along with a  
count of how many threads have that same stack.

I use the glibc backtrace function to get the backtrace, and then use  
popen to execute addr2line and convert memory addresses to file  
names, function names, and line numbers.  If glibc isn't available,  
_st_print_thread_stacks just prints a warning.  And this feature is  
only available if DEBUG is turned on.

We've found this feature extremely helpful when debugging.  To see a  
demo, try running the program:
http://abdelmalek.org/test-backtrace.c
using StateThreads with the patch below.

I've also put the patch and new file at:
http://abdelmalek.org/st-patch-1
http://abdelmalek.org/backtrace.c

The patch can be a bit more robust (it assumes addr2line exists).   
But I didn't want to go through the hassle of doing this, if the  
StateThreads community doesn't want to use this patch.  (In our  
environment, addr2line will always be there.)

Cheers,
Mike


diff -ubr st-1.5.1.clean/Makefile st/Makefile
--- st-1.5.1.clean/Makefile     2004-05-14 01:43:40.000000000 -0400
+++ st/Makefile 2005-05-07 16:24:08.000000000 -0400
@@ -247,7 +247,8 @@
                $(TARGETDIR)/stk.o   \
                $(TARGETDIR)/sync.o  \
                $(TARGETDIR)/key.o   \
-              $(TARGETDIR)/io.o
+              $(TARGETDIR)/io.o \
+              $(TARGETDIR)/backtrace.o
OBJS        += $(EXTRA_OBJS)
HEADER      = $(TARGETDIR)/st.h
SLIBRARY    = $(TARGETDIR)/libst.a
diff -ubr st-1.5.1.clean/common.h st/common.h
--- st-1.5.1.clean/common.h     2004-01-11 17:18:15.000000000 -0500
+++ st/common.h 2005-05-07 15:34:17.000000000 -0400
@@ -360,8 +360,18 @@
   */
#ifdef DEBUG
-void _st_iterate_threads(void);
-#define ST_DEBUG_ITERATE_THREADS() _st_iterate_threads()
+typedef void(*_st_func_ptr_t)(_st_thread_t *thread,
+                              int           start_flag,
+                              int           end_flag);
+/* Pointer to function that will be called on thread switch */
+extern _st_func_ptr_t _st_iterate_func_ptr;
+extern int _st_iterate_threads_flag;
+/* Thread iteration function that will call an arbitrary function */
+extern void _st_iterate_threads_helper(_st_func_ptr_t func);
+#define ST_DEBUG_ITERATE_THREADS()                               \
+          if (_st_iterate_func_ptr) {                            \
+              _st_iterate_threads_helper(_st_iterate_func_ptr);  \
+          }
#else
#define ST_DEBUG_ITERATE_THREADS()
#endif
@@ -370,6 +380,7 @@
   * Switch away from the current thread context by saving its state and
   * calling the thread scheduler
   */
+
#define _ST_SWITCH_CONTEXT(_thread)       \
      ST_BEGIN_MACRO                        \
      if (!MD_SETJMP((_thread)->context)) { \
diff -ubr st-1.5.1.clean/public.h st/public.h
--- st-1.5.1.clean/public.h     2004-05-14 01:40:30.000000000 -0400
+++ st/public.h 2005-05-07 15:25:53.000000000 -0400
@@ -157,8 +157,10 @@
extern st_netfd_t st_open(const char *path, int oflags, mode_t mode);
#ifdef DEBUG
-extern void _st_show_thread_stack(st_thread_t thread, const char  
*messg);
+extern void _st_show_thread_stack(st_thread_t thread, int start_flag,
+                                  int end_flag);
extern void _st_iterate_threads(void);
+extern void _st_print_thread_stacks(int ignore);
#endif
#ifdef __cplusplus
diff -ubr st-1.5.1.clean/sched.c st/sched.c
--- st-1.5.1.clean/sched.c      2004-05-14 01:40:02.000000000 -0400
+++ st/sched.c  2005-05-07 15:40:22.000000000 -0400
@@ -904,16 +904,13 @@
#ifdef DEBUG
-/* ARGSUSED */
-void _st_show_thread_stack(_st_thread_t *thread, const char *messg)
-{
-
-}
-
/* To be set from debugger */
int _st_iterate_threads_flag = 0;
+/* Thread iteration function that will call an arbitrary function */
+_st_func_ptr_t _st_iterate_func_ptr = NULL;
-void _st_iterate_threads(void)
+/* This function iterates over all threads, calling "func" for each  
thread. */
+void _st_iterate_threads_helper(_st_func_ptr_t func)
{
    static _st_thread_t *thread = NULL;
    static jmp_buf orig_jb, save_jb;
@@ -929,16 +926,20 @@
    if (thread) {
      memcpy(thread->context, save_jb, sizeof(jmp_buf));
-    _st_show_thread_stack(thread, NULL);
+    func(thread, 0, 0);
    } else {
      if (MD_SETJMP(orig_jb)) {
        _st_iterate_threads_flag = 0;
+      _st_iterate_func_ptr = NULL;
        thread = NULL;
-      _st_show_thread_stack(thread, "Iteration completed");
+      /* Last thread to iterate through  */
+      func(thread, 0, 1);
        return;
      }
+    /* First thread to iterate through  */
      thread = _ST_CURRENT_THREAD();
-    _st_show_thread_stack(thread, "Iteration started");
+    _st_iterate_func_ptr = func;
+    func(thread, 1, 0);
    }
    q = thread->tlink.next;
@@ -951,5 +952,18 @@
    memcpy(save_jb, thread->context, sizeof(jmp_buf));
    MD_LONGJMP(thread->context, 1);
}
+
+/* ARGSUSED */
+void _st_show_thread_stack(_st_thread_t *thread, int start_flag, int  
end_flag)
+{
+}
+
+
+/* Iterate over threads inside debugger; see st/README */
+void _st_iterate_threads(void)
+{
+    _st_iterate_threads_helper(_st_show_thread_stack);
+}
+
#endif /* DEBUG */


New file: backtrace.c:
/*
* The contents of this file are subject to the Mozilla Public
* License Version 1.1 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.mozilla.org/MPL/
*
* Software distributed under the License is distributed on an "AS
* IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
* implied. See the License for the specific language governing
* rights and limitations under the License.
*
* Contributor(s):  Michael Abd-El-Malek (mab...@cm...)
*                  Carnegie Mellon University
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 or later (the
* "GPL"), in which case the provisions of the GPL are applicable
* instead of those above.  If you wish to allow use of your
* version of this file only under the terms of the GPL and not to
* allow others to use your version of this file under the MPL,
* indicate your decision by deleting the provisions above and
* replace them with the notice and other provisions required by
* the GPL.  If you do not delete the provisions above, a recipient
* may use your version of this file under either the MPL or the
* GPL.
*/



/*
* This file contains routines for printing a stack trace of all threads.
* Only works when DEBUG is defined and where glibc is available,  
since it
* provides the backtrace() function.
*/

#define _GNU_SOURCE  /* to get program_invocation_name */

#include <stdio.h>
#include <stdlib.h>


#if defined(DEBUG) && defined(__GLIBC__)

#include <errno.h>
#include "common.h"
#include <execinfo.h>
#include <inttypes.h>
#include <string.h>


/* The maximum number of frames to get a stack trace for.  If a  
thread has more
* frames than this, then we only show the latest X frames. */
#define MAX_NUM_FRAMES 64


typedef struct thread_stack_s {
   uint32_t        num_frames;
   void*           addresses[MAX_NUM_FRAMES]; /* frame pointers */
   char*           locations[MAX_NUM_FRAMES]; /* file/function/line  
numbers  */
   uint32_t        num_matches;

   struct thread_stack_s* next;
} thread_stack_t;

static thread_stack_t* stacks = NULL;


/* Converts the function's memory addresses to function names, file  
names, and
* line numbers.  Calls binutil's addr2line program. */
static void get_symbol_names(thread_stack_t *stack)
{
     char program_to_run[1024], function[256], filename_lineno[256],  
temp[19];
     FILE* output;
     int num_bytes_left;
     uint32_t i;

     /* Construct the arguments to addr2line */
     num_bytes_left = sizeof(program_to_run);
     num_bytes_left -= snprintf(program_to_run, sizeof(program_to_run),
                                "addr2line -fCe %s",  
program_invocation_name);
     for (i = 0; i < stack->num_frames && num_bytes_left > 0; ++i) {
         num_bytes_left -= snprintf(temp, sizeof(temp), " %p", stack- 
 >addresses[i]);
         strncat(program_to_run, temp, num_bytes_left);
     }

     /* Use popen to execute addr2line and read its ouput */
     output = popen(program_to_run, "r");
     for (i = 0; i < stack->num_frames; ++i) {
         char* function_listing = (char*) malloc(512);
         fscanf(output, "%255s\n", function);
         fscanf(output, "%255s\n", filename_lineno);
         snprintf(function_listing, 512, "%s at %s", function,  
filename_lineno);
         stack->locations[i] = function_listing;
     }
     pclose(output);
}


static void print_stack(thread_stack_t* stack)
{
     int skip_offset = 0, cmp_len;
     uint32_t i;

     /* Get the function names/filenames/line numbers */
     get_symbol_names(stack);

     cmp_len = strlen("_st_iterate_threads_helper");

     /* Print the backtrace */
     for (i = 0; i < stack->num_frames; ++i) {
         /* Skip frames we don't have location info for */
         if (!strncmp(stack->locations[i], "??", 2)) {
             continue;
         }

         /* Skip the frames that are used for printing the stack  
trace */
         if (skip_offset) {
             printf("\t#%2d %s %p\n", i - skip_offset, stack- 
 >locations[i],
                    stack->addresses[i]);
         } else if (!strncmp(stack->locations[i],  
"_st_iterate_threads_helper",
                             cmp_len)) {
             skip_offset = i + 1;
         }
     }
}


static void add_current_thread_stack(void)
{
     thread_stack_t *new_stack = malloc(sizeof(thread_stack_t));
     thread_stack_t *search;

     /* Call glibc function to get the backtrace */
     new_stack->num_frames = backtrace(new_stack->addresses,  
MAX_NUM_FRAMES);

     /* Check if we have another stacks that is equivalent.  If so,  
then coaelsce
      *  two stacks into one, to minimize output to user. */
     search = stacks;
     while (search) {
         if (search->num_frames == new_stack->num_frames &&
             !memcmp(search->addresses, new_stack->addresses,
                     search->num_frames * sizeof(void*))) {
             /* Found an existing stack that is the same as this  
thread's stack */
             ++search->num_matches;
             free(new_stack);
             return;
         } else {
             search = search->next;
         }
     }

     /* This is a new stack.  Add it to the list of stacks. */
     new_stack->num_matches = 1;
     new_stack->next = stacks;
     stacks = new_stack;
}

static void print_stack_frames(void)
{
     while (stacks) {
         printf("\n%u thread(s) with this backtrace:\n", stacks- 
 >num_matches);
         print_stack(stacks);
         stacks = stacks->next;
     }
     printf("\n");
}

static void free_stacks(void)
{
     uint32_t i;
     while (stacks) {
         thread_stack_t *next = stacks->next;
         for (i = 0; i < stacks->num_frames; ++i) {
             free(stacks->locations[i]);
         }
         free(stacks);
         stacks = next;
     }
     stacks = NULL;
}


static void st_print_thread_stack(_st_thread_t *thread, int start_flag,
                                   int end_flag)
{
     if (end_flag == 0) {
         add_current_thread_stack();
     } else {
         print_stack_frames();
     }
}


void _st_print_thread_stacks(int ignore)
{
     _st_iterate_threads_flag = 1;
     _st_iterate_threads_helper(st_print_thread_stack);
     _st_iterate_threads_flag = 0;

     /* Deallocate memory */
     free_stacks();
}

#else  /* defined(DEBUG) && defined(__GLIBC__) */

void _st_print_thread_stacks(int ignore)
{
     printf("%s: need DEBUG mode and glibc-specific functions to read  
stack.\n",
            __FUNCTION__);
}
#endif /* defined(DEBUG) && defined(__GLIBC__) */

[ST-devel] Patch: compiling under Mac OS X

[Michael Abd-El-M. <mab...@cm...>]

Hello,

To compile ST under Mac OS X (Tiger), I needed to make a small change  
to get some header file correctly included.  Here's the patch.

Cheers,
Mike

[ST-devel] Re: Port for BSD/OS?

[Gene <ge...@co...>]

I think it should be relatively easy to port to bsdi using NSPR (again) 
as the source:
http://lxr.mozilla.org/nspr/source/nsprpub/pr/include/md/_bsdi.h

Can someone with access to BSD/OS patch md.h and try it?
I think for bsdi 4.x the _PR_BSDI_JMPBUF_IS_STRUCT macro
should be defined (see link above).

It's interesting that this OS is still in use. From wikipedia:
"The OS was purchased by Wind River Systems in 2001. Wind River 
discontinued sales of BSD/OS at the end of 2003, with support 
terminating at the end of 2004."

--Gene

On May 1, 2005, at 8:37 AM, Claus Assmann wrote:

> Does someone have a port for BSD/OS? It seems simply re-using
> the FreeBSD part doesn't work (at least that's what has been
> reported to me).
>
> BSD/OS 4.3.1 using gcc 3.X
>
> source='sched.c' object='sched.o' libtool=no  depfile='.deps/sched.Po' 
> tmpdepfile='.deps/sched.TPo'  depmode=gcc3 /bin/sh ./depcomp  
> /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I. -I./../include    -DFREEBSD 
> -O -g -O9 -Wall -march=i686 -c `test -f 'sched.c' || echo './'`sched.c
> sched.c: In function `st_thread_create':
> sched.c:877: structure has no member named `_jb'
> *** Error code 1 (continuing)
>

[ST-devel] Port for BSD/OS?

[Claus A. <sta...@es...>]

Does someone have a port for BSD/OS? It seems simply re-using
the FreeBSD part doesn't work (at least that's what has been
reported to me).

BSD/OS 4.3.1 using gcc 3.X

source='sched.c' object='sched.o' libtool=no  depfile='.deps/sched.Po' tmpdepfile='.deps/sched.TPo'  depmode=gcc3 /bin/sh ./depcomp  /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I. -I./../include    -DFREEBSD -O -g -O9 -Wall -march=i686 -c `test -f 'sched.c' || echo './'`sched.c
sched.c: In function `st_thread_create':
sched.c:877: structure has no member named `_jb'
*** Error code 1 (continuing)

[ST-devel] Port for SunOS 5.10 for amd64

[Claus A. <sta...@es...>]

Below is a hack for SunOS 5.10 when running in 64 bit mode on an
AMD64 processor (using gcc 3.x with -m64). I simply copied my earlier
hack for OpenBSD/AMD64, so this might not be the right way to do
it.  Can someone please check this? Thanks!


--- md.h	Sat Jan 29 21:22:00 2005
+++ /tmp/sm-9/md.h	Sun Apr 24 18:27:44 2005
@@ -554,6 +554,13 @@
   (_thread)->context[4] = (long) (_sp);      \
   (_thread)->context[5] = (long) _main;      \
   ST_END_MACRO
+#elif defined(__amd64__)
+#define MD_INIT_CONTEXT(_thread, _sp, _main)   \
+  ST_BEGIN_MACRO                               \
+  if (MD_SETJMP((_thread)->context))           \
+    _main();                                   \
+  (_thread)->context[6] = (long) (_sp); \
+  ST_END_MACRO
 #else
 #error Unknown CPU architecture
 #endif

[ST-devel] [PATCH] context switch callback enhancement for state_threads.

[Alfred P. <br...@mu...>]

We have an app here at Yahoo and we need to know when threads switch
to each other.  I have put together a patch against 1.5.1 here:

http://www.mu.org/~bright/stuff/st.diff

It allows one to set callbacks for when a thread is switched in and
out under st threads.

Documentation has also been updated to reflect the new functions.

Right now we're using it for profiling, but there's a lot of
other potential uses for using this code to extend st_threads.

I'd like to keep it under the "normal" build as runtime enabling
of these callbacks can be effecient as there's only a single pointer
check when they are not enabled.

thank you!

-- 
- Alfred Perlstein <alfredp at yahoo-inc.com>

Re: [ST-devel] Anyone testing 1.5?

[Claus A. <sta...@es...>]

On Wed, Dec 01, 2004, Mike Abbott wrote:
> Has anyone used st-1.5.1 enough that they can vouch that it's stable?

I'm using it in my MTA (sendmail X) and haven't found a problem (yet).

[ST-devel] Anyone testing 1.5?

[Mike A. <mj...@co...>]

Has anyone used st-1.5.1 enough that they can vouch that it's stable?
I'm locked in to using 1.4 right now.  Thanks.
--
Mike Abbott    ma...@us...
State Threads Project co-administrator

[ST-devel] Small cleanup possible?

[Wojtek N. <wo...@po...>]

Hello,

With the introduction of the timeout heap, is it possible for those two
_st_thread members below to be used at the same time?

Regards,
Wojtek Narczynski


struct _st_thread {

  /* (...) */

  _st_clist_t links;      /* For putting on run/sleep/zombie queue */
  _st_clist_t wait_links; /* For putting on mutex/condvar wait queue */

  /* (...) */

};

Re: [ST-devel] AMD64 FreeBSD port works 99.9% ...

[Mike A. <mj...@co...>]

>     I'm having a rather odd problem with the state threads library on my 
> FreeBSD 5.2.1 amd64 box.

> What doesn't work is *printf() calls with a double arguement.

Are you using st_randomize_stacks()?  If so, try changing the constant
0x7 to 0xf in _st_stack_new() in stk.c.  Let me know if this WAG helps.

[ST-devel] Re: AMD64 FreeBSD port works 99.9% ...

[<ge...@co...>]

Hmm, I looked into native FreeBSD implementation of threads in libc_r.  It's pure user-land threads and thread context switching is implemented the same way as ST's (via setjmp/longjmp).  You are right, MD_JB_SP should be 2 for amd64 as seen from pthread_private.h (http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc_r/uthread/pthread_private.h)

#define	SET_STACK_JB(jb, stk)	(jb)[0]._jb[2] = (long)(stk)

It seems that the only amd64-specific code is in uthread_init.c (http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc_r/uthread/uthread_init.c):

#if defined(__amd64__)
		stackp &= ~0xFUL;
#endif

Which should be fine with ST, cause we make stack 64-byte aligned there.
So I can't see any obvious differences between ST and libc_r threads for amd64.  Am I missing something?

--Gene


> Hello,
>     I'm having a rather odd problem with the state threads library on my 
> FreeBSD 5.2.1 amd64 box. I have worked past the MD_JB_SP problem with the 
> following fix...
> 
> #elif defined(__amd64__)
> #define MD_JB_SP   2
> #else
> ...
> 
> added to the freebsd section of md.h. This is the same value as __i386__ and 
> is the only one that seems to work for me. Everything else results in a bus 
> error inside of st some where on start up.
> 
> This is the only change I have made to st to get my app to work 99.9% of the 
> time. What doesn't work is *printf() calls with a double arguement. (I'm 
> using doubles to determine high precision timing values). There utlimately 
> ends up being a bus error in libc in any of the printf() calls. I've tracked 
> the problem down to a problem with va_start(). The va_*() calls manipulate 
> the stack and that seems to get out of whack when trying to print doubles. 
> Crazy. :) All other *printf() calls work fine as long as I don't try to do 
> anything with doubles.
> 
> I'd like to know if anyone else is seeing this kind of problem or if anyone 
> has an idea of how to fix this. I'm surprised I was able to get ST to work 
> at all with such a small fix to md.h. Maybe I'm missing something else 
> important? Is someone working on an official port for FreeBS on amd64?
> 
> cheers,
> Ray
> 
> _________________________________________________________________
> Is your PC infected? Get a FREE online computer virus scan from McAfee® 
> Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> State-threads-devel mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/state-threads-devel

[ST-devel] AMD64 FreeBSD port works 99.9% ...

[Raymond B. <ra...@ho...>]

Hello,
    I'm having a rather odd problem with the state threads library on my 
FreeBSD 5.2.1 amd64 box. I have worked past the MD_JB_SP problem with the 
following fix...

#elif defined(__amd64__)
#define MD_JB_SP   2
#else
...

added to the freebsd section of md.h. This is the same value as __i386__ and 
is the only one that seems to work for me. Everything else results in a bus 
error inside of st some where on start up.

This is the only change I have made to st to get my app to work 99.9% of the 
time. What doesn't work is *printf() calls with a double arguement. (I'm 
using doubles to determine high precision timing values). There utlimately 
ends up being a bus error in libc in any of the printf() calls. I've tracked 
the problem down to a problem with va_start(). The va_*() calls manipulate 
the stack and that seems to get out of whack when trying to print doubles. 
Crazy. :) All other *printf() calls work fine as long as I don't try to do 
anything with doubles.

I'd like to know if anyone else is seeing this kind of problem or if anyone 
has an idea of how to fix this. I'm surprised I was able to get ST to work 
at all with such a small fix to md.h. Maybe I'm missing something else 
important? Is someone working on an official port for FreeBS on amd64?

cheers,
Ray

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: [ST-devel] Port for amd64?

[Wesley W. T. <we...@te...>]

On Sat, Aug 14, 2004 at 08:07:59PM -0700, Mike Abbott wrote:
> st-1.5.0+ support amd64 on Linux (but not OpenBSD).  Please let me know
> if Claus's patch for OpenBSD/AMD64 really works and I'll include it in
> the next release.

Oop. Somehow I missed that there even was a 1.5.0, let alone a 1.5.1.
Time to upload it to debian I suppose.

-- 
Wesley W. Terpstra

Re: [ST-devel] Port for amd64?

[Mike A. <mj...@co...>]

st-1.5.0+ support amd64 on Linux (but not OpenBSD).  Please let me know
if Claus's patch for OpenBSD/AMD64 really works and I'll include it in
the next release.

[ST-devel] Re: Port for amd64?

[Claus A. <sta...@es...>]

Ok, I checked mozilla/nsprpub/pr/include/md/ and created a small
patch for OpenBSD/amd64. I don't know whether that's really all
that is needed, but the basic example programs work.


--- md.h	Thu Jan 15 08:08:17 2004
+++ md.h	Fri Aug 13 21:34:43 2004
@@ -478,6 +481,8 @@
 #define MD_JB_SP  34
 #elif defined(__sparc__)
 #define MD_JB_SP   0
+#elif defined(__amd64__)
+#define MD_JB_SP   6
 #else
 #error Unknown CPU architecture
 #endif

Re: [ST-devel] Port for amd64?

[Wesley W. T. <we...@te...>]

On Fri, Aug 13, 2004 at 07:08:37AM -0700, Claus Assmann wrote:
> Has someone already ported statethreads to amd64? I would like
> to run it under OpenBSD (and maybe others) in 64bit mode.

I have a bug filed against me for the debian package to this effect.
I also run amd64 at home.

So, in ~10 days I will definitely port it to linux/amd64.
(Though not *BSD or Solaris since I don't have these)

If you need it before then, you'll have to do it yourself.
Send me a copy, though. :-)

PS. It should be quite easy; I believe the i386 code would probably
work without change, but I am not at home and can't confirm this.

It is conceivable that the new amd64 registers changed the location of 
th stack pointer in jmpbuf, but I doubt it.

Try changing md.h, lines 153, 374, 433, 465, and 530 from
#(el)if defined(__i386__)
to
#(el)if defined(__i386__) || defined(__x86_64__)

Good luck!

-- 
Wesley W. Terpstra

[ST-devel] Port for amd64?

[Claus A. <sta...@es...>]

Has someone already ported statethreads to amd64? I would like
to run it under OpenBSD (and maybe others) in 64bit mode.