Nabble - State Threads

Private symbols

2009-10-31T19:18:30Z

I recently updated the packaging for libst 1.9 in debian and happened
to notice that there are a number of private symbols leaked into the
shared library. Attached is a patch that I've applied in the debian
package to fix this issue. Please consider applying it upstream.

Thank you.

PS. I am not subscribed so please CC me on any replies.

[01-private-symbols.patch]

diff -Nur -x '*.orig' -x '*~' st-1.9/common.h st-1.9.new/common.h --- st-1.9/common.h 2009-11-01 02:36:41.000000000 +0100 +++ st-1.9.new/common.h 2009-11-01 02:37:14.000000000 +0100 @@ -252,9 +252,12 @@ * Current vp, thread, and event system */ -extern _st_vp_t _st_this_vp; -extern _st_thread_t *_st_this_thread; -extern _st_eventsys_t *_st_eventsys; +ST_PRIVATE extern _st_vp_t _st_this_vp; +ST_PRIVATE extern _st_thread_t *_st_this_thread; +ST_PRIVATE extern _st_eventsys_t *_st_eventsys; +ST_PRIVATE extern int _st_active_count; +ST_PRIVATE extern time_t _st_curr_time; +ST_PRIVATE extern st_utime_t _st_last_tset; #define _ST_CURRENT_THREAD() (_st_this_thread) #define _ST_SET_CURRENT_THREAD(_thread) (_st_this_thread = (_thread)) @@ -439,16 +442,15 @@ * Forward declarations */ -void _st_vp_schedule(void); -void _st_vp_check_clock(void); -void *_st_idle_thread_start(void *arg); -void _st_thread_main(void); -void _st_thread_cleanup(_st_thread_t *thread); -void _st_add_sleep_q(_st_thread_t *thread, st_utime_t timeout); -void _st_del_sleep_q(_st_thread_t *thread); -_st_stack_t *_st_stack_new(int stack_size); -void _st_stack_free(_st_stack_t *ts); -int _st_io_init(void); +ST_PRIVATE void _st_vp_schedule(void); +ST_PRIVATE void _st_vp_check_clock(void); +ST_PRIVATE void *_st_idle_thread_start(void *arg); +ST_PRIVATE void _st_thread_cleanup(_st_thread_t *thread); +ST_PRIVATE void _st_add_sleep_q(_st_thread_t *thread, st_utime_t timeout); +ST_PRIVATE void _st_del_sleep_q(_st_thread_t *thread); +ST_PRIVATE _st_stack_t *_st_stack_new(int stack_size); +ST_PRIVATE void _st_stack_free(_st_stack_t *ts); +ST_PRIVATE int _st_io_init(void); st_utime_t st_utime(void); _st_cond_t *st_cond_new(void); diff -Nur -x '*.orig' -x '*~' st-1.9/md.h st-1.9.new/md.h --- st-1.9/md.h 2009-11-01 02:37:12.000000000 +0100 +++ st-1.9.new/md.h 2009-11-01 02:37:14.000000000 +0100 @@ -54,6 +54,12 @@ #define MAP_FAILED -1 #endif +#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4) +#define ST_PRIVATE __attribute__((visibility("hidden"))) +#else +#define ST_PRIVATE +#endif + /***************************************** * Platform specifics */ @@ -460,8 +466,8 @@ #define MD_SETJMP(env) _st_md_cxt_save(env) #define MD_LONGJMP(env, val) _st_md_cxt_restore(env, val) -extern int _st_md_cxt_save(jmp_buf env); -extern void _st_md_cxt_restore(jmp_buf env, int val); +ST_PRIVATE extern int _st_md_cxt_save(jmp_buf env); +ST_PRIVATE extern void _st_md_cxt_restore(jmp_buf env, int val); #else #define MD_SETJMP(env) setjmp(env) #define MD_LONGJMP(env, val) longjmp(env, val) diff -Nur -x '*.orig' -x '*~' st-1.9/md.S st-1.9.new/md.S --- st-1.9/md.S 2009-11-01 02:36:41.000000000 +0100 +++ st-1.9.new/md.S 2009-11-01 02:37:14.000000000 +0100 @@ -302,6 +302,7 @@ /* _st_md_cxt_save(__jmp_buf env) */ .globl _st_md_cxt_save +.hidden _st_md_cxt_save .type _st_md_cxt_save, @function .align 16 _st_md_cxt_save: @@ -330,6 +331,7 @@ /* _st_md_cxt_restore(__jmp_buf env, int val) */ .globl _st_md_cxt_restore +.hidden _st_md_cxt_restore .type _st_md_cxt_restore, @function .align 16 _st_md_cxt_restore: @@ -375,6 +377,7 @@ /* _st_md_cxt_save(__jmp_buf env) */ .globl _st_md_cxt_save +.hidden _st_md_cxt_save .type _st_md_cxt_save, @function .align 16 _st_md_cxt_save: @@ -402,6 +405,7 @@ /* _st_md_cxt_restore(__jmp_buf env, int val) */ .globl _st_md_cxt_restore +.hidden _st_md_cxt_restore .type _st_md_cxt_restore, @function .align 16 _st_md_cxt_restore: diff -Nur -x '*.orig' -x '*~' st-1.9/sched.c st-1.9.new/sched.c --- st-1.9/sched.c 2009-10-02 02:22:17.000000000 +0200 +++ st-1.9.new/sched.c 2009-11-01 02:37:35.000000000 +0100 @@ -312,7 +312,7 @@ } -void _st_thread_main(void) +ST_HIDDEN void _st_thread_main(void) { _st_thread_t *thread = _ST_CURRENT_THREAD(); diff -Nur -x '*.orig' -x '*~' st-1.9/stk.c st-1.9.new/stk.c --- st-1.9/stk.c 2009-11-01 02:36:41.000000000 +0100 +++ st-1.9.new/stk.c 2009-11-01 02:37:14.000000000 +0100 @@ -50,9 +50,9 @@ /* How much space to leave between the stacks, at each end */ #define REDZONE _ST_PAGE_SIZE -_st_clist_t _st_free_stacks = ST_INIT_STATIC_CLIST(&_st_free_stacks); -int _st_num_free_stacks = 0; -int _st_randomize_stacks = 0; +ST_HIDDEN _st_clist_t _st_free_stacks = ST_INIT_STATIC_CLIST(&_st_free_stacks); +ST_HIDDEN int _st_num_free_stacks = 0; +ST_HIDDEN int _st_randomize_stacks = 0; static char *_st_new_stk_segment(int size); diff -Nur -x '*.orig' -x '*~' st-1.9/sync.c st-1.9.new/sync.c --- st-1.9/sync.c 2009-11-01 02:36:41.000000000 +0100 +++ st-1.9.new/sync.c 2009-11-01 02:37:14.000000000 +0100 @@ -44,14 +44,8 @@ #include <errno.h> #include "common.h" - -extern time_t _st_curr_time; -extern st_utime_t _st_last_tset; -extern int _st_active_count; - static st_utime_t (*_st_utime)(void) = NULL; - /***************************************** * Time functions */

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
State-threads-devel mailing list
State-threads-devel@...
https://lists.sourceforge.net/lists/listinfo/state-threads-devel

From forum: State-Threads - Dev

ST 1.9

2009-10-01T19:38:48Z

Version 1.9 of the State Threads Library is now available. It adds
support for Intel Macs and fixes some compilation issues.

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

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
State-threads-announce mailing list
State-threads-announce@...
https://lists.sourceforge.net/lists/listinfo/state-threads-announce

From forum: State-Threads - Announce

General

2008-09-11T00:06:47Z

Its a very good website.
Great idea for posting questions, suggestion, and information.
We can come up with new ideas.
==========================================
Harry
auto auctions

From forum: State-Threads - Dev

ST 1.8

2007-03-15T12:19:18Z

Version 1.8 of the State Threads Library is now available. It adds
support for kqueue and epoll, adds st_readv(), st_readv_resid() and
st_writev_resid(), and finally defines ST_UTIME_NO_TIMEOUT and
ST_UTIME_NO_WAIT.

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

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
State-threads-announce mailing list
State-threads-announce@...
https://lists.sourceforge.net/lists/listinfo/state-threads-announce

From forum: State-Threads - Announce

[Jruby-devel] fwd: Do away with card balances or loans - acct Andrea42004155

2006-10-26T12:50:36Z

propane disruptivestockroom
Our attorneys have discovered a loop hole in the banking laws. canyon.

Using this discovery we have been successful at totally eliminating peoples CreditCardDebt with out them paying another dime. imbrue.

We GuaranteeThat we can do this for you. mulct.

Follow here to find out how tor.

crystallography telegraphy eyesight

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jruby-devel mailing list
Jruby-devel@...
https://lists.sourceforge.net/lists/listinfo/jruby-devel

From forum: State-Threads - Announce

ST 1.7

2006-05-31T00:20:44Z

Version 1.7 of the State Threads Library is now available. It supports
glibc 2.4, which breaks programs that manipulate jump buffers. Download
it from: http://state-threads.sourceforge.net/

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

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
State-threads-announce mailing list
State-threads-announce@...
https://lists.sourceforge.net/lists/listinfo/state-threads-announce

From forum: State-Threads - Announce

Re: Re: Compile problem under Linux Fedora 5

2006-04-06T01:40:58Z

Gene wrote:

> Hmm, I have a sneaky suspicion that they finally made JB_SP a private
> definition in new version of glibc (2.4). It's still defined internally in
> sysdeps/i386/jmpbuf-offsets.h
>
> Simple fix is to add this missing macro in md.h in the LINUX section:
>
> #elif defined(__i386__)
> #define MD_STACK_GROWS_DOWN
>
> #if defined(__GLIBC__) && __GLIBC__ >= 2
> #ifndef JB_SP
> /* From sysdeps/i386/jmpbuf-offsets.h in glibc 2.4 */
> #define JB_SP 4
> #endif
> #define MD_GET_SP(_t) (_t)->context[0].__jmpbuf[JB_SP]
> #else
>
> Please give it a try. If it works, we'll add this to the next ST release.

I've already did it. It segfaults. 8-(

Moreover, Fedora 5 come with glibc 2.4.4 (not the official 2.4 release).

For a reason I don't know, the glibc installed with Fedora 5 doesn't
have this header file (jmpbuf-offsets.h). glibc 2.4 (glibc from gnu web
site has this header but not Fedora distributed glibc).

glibc versions are :

# rpm -qa|grep glibc
glibc-devel-2.4-4
glibc-kernheaders-3.0-5.2
glibc-2.4-4
glibc-common-2.4-4
glibc-headers-2.4-4

Odd thing 8-(

--
---------------------------------------------------------------
Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41
Ecole des Mines de Paris http://j-chkmail.ensmp.fr
60, bd Saint Michel http://www.ensmp.fr/~martins
75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@...

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
State-threads-devel mailing list
State-threads-devel@...
https://lists.sourceforge.net/lists/listinfo/state-threads-devel

From forum: State-Threads - Dev

Re: asynchronous fsync()

2006-03-07T09:06:30Z

* Mike Abbott <mja63@...> [060307 09:04] wrote:
> > Is there any way to make fsync() asynchronous
>
> My first guess would be No, because ST requires non-blocking I/O and
> descriptors to disk files can't be made non-blocking. But I'll talk
> with Gene about it. You mentioned async I/O but that's its own can of
> worms. I've never relied on SIGIO; let me know how it works for you :).
>
> If I were faced with this I would do the typical ST thing and spawn a
> persistent helper process.

You're right, you'd need a helper process to do this.

fsync(2) can not be made async.

--
- Alfred Perlstein
- CTO Okcupid.com / FreeBSD Hacker / All that jazz -

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
State-threads-devel mailing list
State-threads-devel@...
https://lists.sourceforge.net/lists/listinfo/state-threads-devel

From forum: State-Threads - Dev

Re: asynchronous fsync()

2006-03-07T09:05:09Z

> Is there any way to make fsync() asynchronous

My first guess would be No, because ST requires non-blocking I/O and
descriptors to disk files can't be made non-blocking. But I'll talk
with Gene about it. You mentioned async I/O but that's its own can of
worms. I've never relied on SIGIO; let me know how it works for you :).

If I were faced with this I would do the typical ST thing and spawn a
persistent helper process.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
State-threads-devel mailing list
State-threads-devel@...
https://lists.sourceforge.net/lists/listinfo/state-threads-devel

From forum: State-Threads - Dev

asynchronous fsync()

2006-03-05T16:23:27Z

Is there any way to make fsync() asynchronous in the context of
statethreads? Currently a process that uses fsync() will block until
fsync() returns thus preventing any other operations from occuring.
Some OSs provide aio_fsync() but so far I have seen only aio_return()
to check for the status of an asynchronous I/O operation, not some
mechanism to get notified when the operation finished. SIGIO might
be another approach to the problem, but signals have their own
problems.

What I would like to see is some support in statethreads to make
fsync() a scheduling point, just like read()/write() for network
I/O. Any pointers/suggestions to accomplish this are welcome!

PS: I know I can use multiple processes to mitigate the problem,
but I am curious whether that limitation of statethreads can be
solved within the library itself (even if it's not portable but
only available for some OSs).

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
State-threads-devel mailing list
State-threads-devel@...
https://lists.sourceforge.net/lists/listinfo/state-threads-devel

From forum: State-Threads - Dev