state-threads-users — State Threads users' list

[ST-users] MySQL++ memory corruption, valgrind

[Drew V. <dv...@in...>]

I'm writing a multiplayer game server that uses MySQL as a backing 
store. I'm using the MySQL++ C++ wrapper for the standard mysql library. 
I am experiencing some memory corruption issues. The corruption appears 
after st_init() and after I setup a listening socket with the st_netfd_t 
functions. It happens before any new threads are created (when I say 
threads, I always mean state threads, I'm not using any pre-emptive 
threads). When I disable the state threads code, the MySQL++ code does 
not exhibit any memory corruption. The memory corruption also disappears 
when I run the code with Valgrind, with the state threads code active. 
The way in which the memory is corrupted is static, so the chance of bad 
RAM is extremely low.

The MySQL++ library that I am linking against is not "thread-safe." I 
was under the impression that since there is no pre-emption, just 
yielding, I did not need to link against a thread-safe library. Do I?

I searched the archives for this list for issues regarding Valgrind, 
MySQL++, and memory corruption in general. Is there anything I need to 
know about MySQL++ or Valgrind?

When you reply, please CC me, as I am not subscribed to this list.

Drew Vogel

[ST-users] Re: BSD/OS 4.3.1

[Dave S. Y. - S. A. a.k.a. T. R. of t. P. <ro...@do...>]

On Mon, Nov 07, 2005 at 01:36:01AM -0800, Gene wrote:
> On Nov 5, 2005, at 5:57 PM, Dave Shariff Yadallee wrote:
> >I am trying to port statethreads to BSD/OS 4.3.1
> 
> Dave,
> 
> Below is a message I sent as a reply to the same question a while ago.
> I think it shouldn't be too hard to do the port.
> 
> --Gene
> 
> 
> Begin forwarded message:
> 
> >From: Gene <ge...@co...>
> >Date: May 7, 2005 1:10:39 AM PDT
> >To: Claus Assmann <sta...@es...>
> >Cc: sta...@li...
> >Subject: Re: Port for BSD/OS?
> >
> >
> >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)
> >>
> >>
> >
> >
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

Actually, I think I got it.  Now I need to know whether the port is
correct. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ST-users] Re: BSD/OS 4.3.1

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

On Nov 5, 2005, at 5:57 PM, Dave Shariff Yadallee wrote:
> I am trying to port statethreads to BSD/OS 4.3.1

Dave,

Below is a message I sent as a reply to the same question a while ago.
I think it shouldn't be too hard to do the port.

--Gene


Begin forwarded message:

> From: Gene <ge...@co...>
> Date: May 7, 2005 1:10:39 AM PDT
> To: Claus Assmann <sta...@es...>
> Cc: sta...@li...
> Subject: Re: Port for BSD/OS?
>
>
> 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-users] BSD/OS 4.3.1

[Dave S. Y. - S. A. a.k.a. T. R. of t. P. <ro...@do...>]

I am trying to port statethreads to BSD/OS 4.3.1

I am running into:

sched.c: In function `st_thread_create':
sched.c:877: structure has no member named `_jb'

Also, I am trying to base the bort on FREEBSD .



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ST-users] 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-users] 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-users] gethostbyaddr equivalent

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

Hi All,

The dns examples have a dns_getaddr function which is the state threads equivalent of
gethostbyname (this includes the improved code in the extensions directory). 
Is there a state threads equivalent to gethostbyaddr function available? Anyone got code lying
around they are willing to share?

Cheers.
C.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [ST-users] epoll and kqueue support

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

> Has there been any work on supporting additional polling mechanisms

I have heard rumors that someone is going to port ST to kqueue soon.  No
details yet.  No epoll rumors.  However, as Gene is fond of pointing
out, any optimizations there are optimizing for the idle case.  That is,
ST calls select/poll/whatever only when it has no other work to do,
which makes it somewhat difficult to justify putting a lot of effort
into making that part faster.  "Do nothing, faster"?

> Passing large array of fd descriptors (~3000) to select()

There are systems that have special optimizations for selecting/polling
a few dozen descriptors at a time.  Perhaps ST could select/poll in
batches ... but that would be another "idle optimization" to get past
Gene.

[ST-users] epoll and kqueue support

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

Hi Group,

Has there been any work on supporting additional polling mechanisms such as epoll (for linux) and
kqueue (for *bsd) ? These mechanisms are meant to be more efficient than poll/select so I'm
interested to see if that is the case.

On a related note, maybe someone here can answer this question:
Passing large array of fd descriptors (~3000) to select() has been known to suffer from the
"thundering herd" problem of both kernel having to scan the array and the calling code having to
scan the array on return from the kernel.
Now my question is: can this be mitigated simply by using more forks (more virtual process, in
state threads speak). ie. If initially there was one process doing select() on 3000 fds, would a
100 process doing select() on 30 fds each perform better? Obviously there would be additional cost
for the kernel to handle scheduling for an additional 99 processes, but which is the lesser evil?

I wish I could test this theory for myself, but we can't touch the production server while it is
running.


Cheers for any insights.
Cuong.

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

[ST-users] Re: Timeout questions

[Koji N. <nam...@gm...>]

I get it!
Thanks for your response.

--
Namekata

On Fri, 24 Dec 2004 09:25:33 +0000, ge...@co...
<ge...@co...> wrote:
> >  1. In the reference, st_netfd_poll() section:
> >
> >     "If the value of timeout is -1, this function blocks
> >      until a requested I/O event occurs or until the call
> >      is interrupted by st_thread_interrupt()".
> >
> >     Is this true for other functions, say, st_accept(),
> >     st_read(), etc.?
> 
> Yes, -1 means infinite timeout for all I/O functions taking
> timeout argument.
> 
> 
> >  2. Is there any reason why ST_UTIME_NO_TIMEOUT is not
> >     in st.h (public.h)?
> 
> I guess the main reason is that "-1" is much shorter than
> "ST_UTIME_NO_TIMEOUT" :)
> 
> According to I/O function prototypes in st.h, timeout value -1 will  be
> treated as (st_utime_t)-1 or -1ULL which is exactly the same as
> ST_UTIME_NO_TIMEOUT.
> 
> --Gene

[ST-users] Re: Timeout questions

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

>  1. In the reference, st_netfd_poll() section:
> 
>     "If the value of timeout is -1, this function blocks
>      until a requested I/O event occurs or until the call 
>      is interrupted by st_thread_interrupt()".
> 
>     Is this true for other functions, say, st_accept(),
>     st_read(), etc.?

Yes, -1 means infinite timeout for all I/O functions taking
timeout argument.


>  2. Is there any reason why ST_UTIME_NO_TIMEOUT is not
>     in st.h (public.h)?

I guess the main reason is that "-1" is much shorter than 
"ST_UTIME_NO_TIMEOUT" :)

According to I/O function prototypes in st.h, timeout value -1 will  be
treated as (st_utime_t)-1 or -1ULL which is exactly the same as
ST_UTIME_NO_TIMEOUT.

--Gene

[ST-users] Timeout questions

[Koji N. <nam...@gm...>]

Hi,

Two questions:

 1. In the reference, st_netfd_poll() section:

    "If the value of timeout is -1, this function blocks
     until a requested I/O event occurs or until the call 
     is interrupted by st_thread_interrupt()".

    Is this true for other functions, say, st_accept(),
    st_read(), etc.?

 2. Is there any reason why ST_UTIME_NO_TIMEOUT is not
    in st.h (public.h)?

Thanks in advance,

--
Namekata

[ST-users] Re: st_connect timeout problem

[Ron A. <ron...@ne...>]

Gene,

I have been trying to do that, but to no avail, still I could not
solve my problem until this weekend.

I'll tell you what happened. My application connects to a lot
of webservers every minute. Between that it just sleep()s.

Well it appeared that I should have read the programming notes on
the State Thread website better, because of the timeout. My program
slept using sleep() (in a source file far away from where I used the
st_*() calls). And when you connect with a timeout value, it is
the timeout _since the last context switch_. Yuk. This caused my
connects to time out faster, the sleeps() in between rounds thus
neede to be longer, and eventually st_connect()s timed out
immediately.

I had a lot of trouble finding it, because in my small testprogram
off course I used st_sleep()...

Maybe you can put something that stresses this behaviour in the
'complete reference', because this has been costing me days and
days to find, and our customers a lot of grief.

Thanks anyway, I really _really_ like State Threads.

Ron Arts

ge...@co... wrote:
> Ron,
> 
> Can you extract a reproducible test case (small fragment) from
> your application and post/email source code? Then we can take a
> look at it and investigate.
> 
> --Gene
> 
>>Hello,
>>
>>I am writing an application that does the following:
>>
>>every minute:
>>
>>- read a list of websites/URLs
>>- connect to each of them
>>- retrieve some info from them
>>- close connection
>>
>>I am using st-1.4 compiled with USE_POLL on redhat
>>linux 9 on i386.
>>
>>The problem: one of the sites in the list is
>>firewalled/unreachable, and that's why I use a timeout
>>parameter of 50 seconds to st_connect.
>>
>>Before I used this parameter, by program hang for
>>4 minutes on that particular site before finishing
>>the main loop.
>>
>>But since I added the timeout parameter another strange
>>thing happened: everything works but after 4 iterations
>>of the main loop (so 4 minutes) most connections
>>suddenly get ETIME on st_connect, and after that
>>I have an irregular pattern of thing going right
>>and things going wrong.
>>
>>Does this ring a bell with anyone? Or should I
>>post this to -devel?
>>
>>Thanks,
>>Ron Arts
>>
>>-- 
>>Netland Internet Services
>>bedrijfsmatige internetoplossingen
>>
>>http://www.netland.nl   Kruislaan 419              1098 VA Amsterdam
>>info: 020-5628282       servicedesk: 020-5628280   fax: 020-5628281
>>
>>Never trust a man who can count to 1,023 on his fingers
> 
> 


-- 
Netland Internet Services
bedrijfsmatige internetoplossingen

http://www.netland.nl   Kruislaan 419              1098 VA Amsterdam
info: 020-5628282       servicedesk: 020-5628280   fax: 020-5628281

DEVICE=EXXON.SYS may mess up your environment

[ST-users] Re: st_connect timeout problem

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

Ron,

Can you extract a reproducible test case (small fragment) from
your application and post/email source code? Then we can take a
look at it and investigate.

--Gene
> Hello,
> 
> I am writing an application that does the following:
> 
> every minute:
> 
> - read a list of websites/URLs
> - connect to each of them
> - retrieve some info from them
> - close connection
> 
> I am using st-1.4 compiled with USE_POLL on redhat
> linux 9 on i386.
> 
> The problem: one of the sites in the list is
> firewalled/unreachable, and that's why I use a timeout
> parameter of 50 seconds to st_connect.
> 
> Before I used this parameter, by program hang for
> 4 minutes on that particular site before finishing
> the main loop.
> 
> But since I added the timeout parameter another strange
> thing happened: everything works but after 4 iterations
> of the main loop (so 4 minutes) most connections
> suddenly get ETIME on st_connect, and after that
> I have an irregular pattern of thing going right
> and things going wrong.
> 
> Does this ring a bell with anyone? Or should I
> post this to -devel?
> 
> Thanks,
> Ron Arts
> 
> -- 
> Netland Internet Services
> bedrijfsmatige internetoplossingen
> 
> http://www.netland.nl   Kruislaan 419              1098 VA Amsterdam
> info: 020-5628282       servicedesk: 020-5628280   fax: 020-5628281
> 
> Never trust a man who can count to 1,023 on his fingers

[ST-users] st_connect timeout problem

[Ron A. <ron...@ne...>]

Hello,

I am writing an application that does the following:

every minute:

- read a list of websites/URLs
- connect to each of them
- retrieve some info from them
- close connection

I am using st-1.4 compiled with USE_POLL on redhat
linux 9 on i386.

The problem: one of the sites in the list is
firewalled/unreachable, and that's why I use a timeout
parameter of 50 seconds to st_connect.

Before I used this parameter, by program hang for
4 minutes on that particular site before finishing
the main loop.

But since I added the timeout parameter another strange
thing happened: everything works but after 4 iterations
of the main loop (so 4 minutes) most connections
suddenly get ETIME on st_connect, and after that
I have an irregular pattern of thing going right
and things going wrong.

Does this ring a bell with anyone? Or should I
post this to -devel?

Thanks,
Ron Arts

-- 
Netland Internet Services
bedrijfsmatige internetoplossingen

http://www.netland.nl   Kruislaan 419              1098 VA Amsterdam
info: 020-5628282       servicedesk: 020-5628280   fax: 020-5628281

Never trust a man who can count to 1,023 on his fingers

[ST-users] Solaris9, gcc 3.3.1, 64bit mode: crash in longjmp()

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

Does anyone use this combination? A simple program crashes
in longjmp():

#0  0xffffffff7ec3b8e8 in longjmp () from /usr/lib/64/libc.so.1
#1  0x00000001000035a0 in _st_vp_schedule () at sched.c:165
#2  0x0000000100004e88 in st_usleep (usecs=4294987380) at sync.c:113
#3  0x0000000100002b48 in main (argc=16777217, argv=0x100006e28) at thr-1.c:120

The program creates one thread and calls st_usleep(timeout); where
timeout is 1000, to force a context switch. Are there any required
changes to the stack context switch code in md.h for this combination?

Re: [ST-users] stateful state-threads

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

> Does that apply to local stack variables too?

No.  Stacks are private to each thread.

Re: [ST-users] stateful state-threads

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

Does that apply to local stack variables too?

> 
> The solution (as always): don't do that. =)
> State threads are still threads and you have to watch out for concurrancy
> issues, just not in code which has nothing to do with I/O.
> 
> -- 
> Wesley W. Terpstra <we...@te...>


http://personals.yahoo.com.au - Yahoo! Personals
New people, new possibilities. FREE for a limited time.

Re: [ST-users] stateful state-threads

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

On Mon, Nov 24, 2003 at 10:20:22PM +1100, Cuong Nguyen wrote:
> Does that mean that on return from a read/write wait state, any shared
> variables may not be in the same state (pardon the pun) that it was left
> in before the long read/write operation?

Yes.

The solution (as always): don't do that. =3D)
State threads are still threads and you have to watch out for concurrancy
issues, just not in code which has nothing to do with I/O.

--=20
Wesley W. Terpstra <we...@te...>

[ST-users] stateful state-threads

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

I'm a little bit confused here...I thought I understood this before, but...

Can someone correct me where I'm wrong please:
- I/O operations should use one of the state thread library's methods (eg. st_read)
- On a call to a long wait read/write, the library is able to switch "context" to 
another state-thread that is ready to be processed.

Does that mean that on return from a read/write wait state, any shared variables may 
not be in the same state (pardon the pun) that it was left in before the long 
read/write operation?
Using the "server" example to illustrate (and simplifying for illustration):


/* global */ 
int r1;

static void *handle_connections(void *arg)
{
[1]  st_netfd_t cli_nfd;

[2]  while (WAIT_THREADS(i) <= max_wait_threads) {
[3]    cli_nfd = st_accept(srv_nfd, (struct sockaddr *)&from, &fromlen, -1);

[4]    st_netfd_setspecific(cli_nfd, &from.sin_addr, NULL);
[5]    st_thread_create(handle_connections, (void *)i, 0, 0);

[6]    handle_session(i, cli_nfd);

[7]    st_netfd_close(cli_nfd);
[8]  }
[9]  return NULL;
}


void handle_session(long srv_socket_index, st_netfd_t cli_nfd)
{
[10]  int r2;
[11]  while ( 1 ) {
[12]     r1 = (int)rand();
[13]     r2 = (int)rand();
[14]     st_read(cli_nfd, buf, sizeof(buf), INFINITE_WAIT);
[15]     DoSomething();
[16]  }

}



The handle_session() function has been converted to be an infinite loop as shown.
If two threads running handle_session() at line 14 had to wait on the client nfd
for a random time interval, does that mean that on return from the read, the global 
variable 'r1' and local variable 'r2' are not guaranteed to be the same as before
the call to st_read() ?
ie.
- thread1 enters handle_session and sets r1 = 111, r2 = 222, then waits via st_read
 for 10 seconds.
- thread2 enters handle_session and sets r2 = 333, r2 = 444, then waits via st_read 
for 15 seconds.
- when thread1 returns, r1 should be 333, but what is r2?...and for that matter, is 
the cli_nfd pointer
different to before thread1 went into wait state via st_read() ???

I'm a little confused because I know nothing about the impact of long_jmp and 
preservation of stack space...well, I know nothing about long_jmp period!


http://personals.yahoo.com.au - Yahoo! Personals
New people, new possibilities. FREE for a limited time.

Re: [ST-users] installation

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

> I am trying to install ST on my linux box...  Can anyone show me how to
> fullly install it and compile the examples?

1. Download st-1.4.tar.gz from state-threads.sourceforge.net.
2. tar xzf st-1.4.tar.gz
3. cd st-1.4
4. gmake linux-debug linux-optimized

The directories LINUX_<version>_DBG and LINUX_<version>_OPT now contain
the compiled binaries, including the examples.

To install the header file and libraries that you just built, copy st.h,
libst.a, and libst.so* to the appropriate places (/usr/include and
/usr/lib, for example).
-- 
Mike Abbott    ma...@us...
State Threads Project co-administrator

[ST-users] installation

[Jonathan A. <jal...@ho...>]

Hello,

I am trying to install ST on my linux box...  Can anyone show me how to =
fullly install it and compile the examples?

Thank you,
Jonathan

[ST-users] Credit, was Re: state-threads / pthreads

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

>     Mike, thank you for State-Threads.

I'm glad you too find it useful, so let's all thank Gene for inventing
it.  He merely lets me stand in the limelight and occasionally
contribute something. :)

[ST-users] Re: state-threads / pthreads interaction on Linux

[Gene S. <gsh...@ak...>]

Sascha Schumann wrote:
> 
>     Hi,
> 
>     has anyone encountered the problem that it is apparently
>     impossible to mix state threads and the pthreads library on
>     Linux?
> 
>     Whenever I access errno in a st-managed thread, I get a
>     segfault.  This is especially true for library wrappers such
>     as connect() etc.
> 

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

Re: [ST-users] state-threads / pthreads interaction on Linux

[Sascha S. <sa...@sc...>]

> I discovered this also.  You also have to avoid librt because it depends
> on libpthread.
>
> My guess is that pthreads is doing some stack and/or heap manipulations
> which are incompatible with those of state threads.

    Since my application needs inter-process locking which won't
    be available through Pthreads/POSIX semaphores until Linux
    2.5, I've added a SysV semaphore set manager to my app and it
    is running beautifully now.

> After doing some research I found out that other projects (e.g. python,
> pth) have had similar difficulties in cygwin with their own jmp_buf tricks.

    Yes, Pth also segfaults with the posted test case on Linux.

    It's great how the next-generation development effort has
    benefitted from State-Threads.  Through on-going refinement,
    the original simple design has been extended to a much more
    complex one.  The State-Threads package has enabled me to
    make tiny steps between each evolutionary change, so that I
    could validate each step.

    Mike, thank you for State-Threads.

    - Sascha