Recent changes to feature-requests

Make state threads, pthread-safe

2009-05-14T00:14:21Z

While state threads makes it easy to write high performance programs, to take advantage of modern CPUs with many cores, you are forced to fork processes and used shared memory to share state. It would be good if state thread was made pthread safe so that state-threads "state" could be managed on a per-pthread basis.

This change should be fairly simple entailing the following:

1) Encapsulate of st statics into a single struct, call it sts
2) Change all the base functions to pass sts as param1 and thus refer to their state via the param1 pointer
3) Convert existing public functions into wrapper functions that refer to a per-process sts
4) Expose new public functions with sts as the first param

Define a version number in st.h to aid portability

2007-09-18T04:31:58Z

With the introduction of new functions in 1.8, it is hard to write portable code that works for both 1.8 and earlier versions of st.

It would be helpful if st.h included some sort of #define of the version so that portable code could be written like this:

#if STVERSION >= 1.8
st_set_eventsys(ST_EVENTSYS_ALT);
#endif

st_init();

etc.

Can we have a st_readv_resid()?

2006-08-11T15:11:29Z

Scatter reads and gather writes provide a great opportunity to avoid
excess data movement within a high throughput daemon. Unfortunately
the current st_ interfaces require that all reads and writes needs to be
marshalled into as a contiguous piece of memory.

On a particular daemon I'm working on, profiling is showing that most of
the user-space CPU is in memory movement and allocation which is
almost entirely as a consequence of this marshalling need.

Can we have an st_writev_resid()?

2006-08-10T21:58:44Z

If a st_thread is managing more than one socket it not's possible to use
st_writev() with a zero timeout since partial write are likely.

The OS returns the bytes written from the underlying writev() so
presumably calculating a resid would be relatively easy.