You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by rb...@apache.org on 2001/09/01 07:10:23 UTC
cvs commit: apr/threadproc/win32 thread.c
rbb 01/08/31 22:10:23
Modified: include/arch/win32 threadproc.h
threadproc/win32 thread.c
Log:
Implement apr_thread_once for Windows.
Revision Changes Path
1.15 +4 -0 apr/include/arch/win32/threadproc.h
Index: threadproc.h
===================================================================
RCS file: /home/cvs/apr/include/arch/win32/threadproc.h,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- threadproc.h 2001/07/24 05:16:32 1.14
+++ threadproc.h 2001/09/01 05:10:23 1.15
@@ -94,5 +94,9 @@
apr_int32_t detached;
};
+struct apr_thread_once_t {
+ long value;
+};
+
#endif /* ! THREAD_PROC_H */
1.36 +17 -0 apr/threadproc/win32/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/win32/thread.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- thread.c 2001/08/03 00:31:43 1.35
+++ thread.c 2001/09/01 05:10:23 1.36
@@ -221,4 +221,21 @@
return APR_SUCCESS;
}
+APR_DECLARE(apr_status_t) apr_thread_once_init(apr_thread_once_t **control,
+ apr_pool_t *p)
+{
+ control = apr_pcalloc(p, sizeof(**control));
+ return APR_SUCCESS;
+}
+
+APR_DECLARE(apr_status_t) apr_thread_once(apr_thread_once_t *control,
+ void (*func)(void))
+{
+ InterlockedIncrement(&control->value);
+ if (control->value == 1) {
+ func();
+ }
+ return APR_SUCCESS;
+}
+
APR_POOL_IMPLEMENT_ACCESSOR_X(thread, cntxt)
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 31 August 2001 22:39, William A. Rowe, Jr. wrote:
> > rbb 01/08/31 22:10:23
> >
> > Modified: include/arch/win32 threadproc.h
> > threadproc/win32 thread.c
> > Log:
> > Implement apr_thread_once for Windows.
> >
> > +APR_DECLARE(apr_status_t) apr_thread_once(apr_thread_once_t *control,
> > + void (*func)(void))
> > +{
> > + InterlockedIncrement(&control->value);
> > + if (control->value == 1) {
> > + func();
> > + }
> > + return APR_SUCCESS;
> > +}
>
> This looks like a possible bug - control->value -could- someday wrap
> (especially if it wasn't called once per thread, but once per some
> operation!) What if we
>
> if (control->value)
> return APR_SUCCESS;
>
> first, which will start null, so several folks might
> fall in (incrementing to perhaps 2, possibly 10, doubtfully 100). But
> everyone hitting that line afterwards gets a fast escape, we're assured it
> was done without the kernel call and without the chance for wrapping.
We could do that. I don't really like the idea of doing one extra if each time this
is called, but it does save a kernel call. Okay, I'll add it right now. :-)
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> rbb 01/08/31 22:10:23
>
> Modified: include/arch/win32 threadproc.h
> threadproc/win32 thread.c
> Log:
> Implement apr_thread_once for Windows.
>
> +APR_DECLARE(apr_status_t) apr_thread_once(apr_thread_once_t *control,
> + void (*func)(void))
> +{
> + InterlockedIncrement(&control->value);
> + if (control->value == 1) {
> + func();
> + }
> + return APR_SUCCESS;
> +}
This looks like a possible bug - control->value -could- someday wrap (especially
if it wasn't called once per thread, but once per some operation!) What if we
if (control->value)
return APR_SUCCESS;
first, which will start null, so several folks might
fall in (incrementing to perhaps 2, possibly 10, doubtfully 100). But everyone
hitting that line afterwards gets a fast escape, we're assured it was done without
the kernel call and without the chance for wrapping.