Re: thread ID
I'm quite aware the code is public, but I thought it would be highly recommended to rely on interfaces rather than copying pasting implementations that might change in future. Days ago I put on this list a question (that went unanswered) concerning the proper way to infer the running mpm name. A core function ap_mpm_name exists, but apparently it's not public. I gather from this thread the conclusion that reproducing the code of the function could be a way to get the information I sought. I don't like it, but at least I have a way to get around my problem. thanks -- Massimo On 03/05/2012 08:21 PM, Rainer Jung wrote: On 05.03.2012 11:33, Massimo Manghi wrote: true, the ID is logged now, but is the function handling the thread id public? not the function, but the source. See function log_tid() in server/log.c. Regards, Rainer
Re: thread ID
On 06.03.2012 09:25, Massimo Manghi wrote: I'm quite aware the code is public, but I thought it would be highly recommended to rely on interfaces rather than copying pasting implementations that might change in future. Days ago I put on this list a question (that went unanswered) concerning the proper way to infer the running mpm name. A core function ap_mpm_name exists, but apparently it's not public. I gather from this thread the conclusion that reproducing the code of the function could be a way to get the information I sought. I don't like it, but at least I have a way to get around my problem. Of course using a public API is much better. In both cases there is none available. Copying code gets problematic, when you start to use e.g. struct members which are not guaranteed to remain unchanged. Concerning the MPM name: If you really are trying to find out, whether an MPM is multi threaded or not, you can use the public MPM query API. It allows to pose questions on the behaviour and config of an MPM and should be better than to rely on its name in many cases. threadId: if you look at log_tid() you will see, that it does not rely on any private API or detailed knowledge abut struct internals. So copying code here should be stable. At least if I didn't miss something. Regards, Rainer
Re: thread ID
On 03/03/2012 07:04 PM, Rainer Jung wrote: On 02.03.2012 00:34, Sorin Manolache wrote: On 03/02/12 00:21, Ben Noordhuis wrote: On Thu, Mar 1, 2012 at 17:29,sorin.manola...@orange.com wrote: Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin What about apr_os_thread_current()? It returns a opaque value that's a pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to understand what that means. As a recovering standards lawyer I should probably point out that pthread_t is an opaque type that's not guaranteed to be convertible to a numeric value (or to anything, really). That said, I've never seen a pthreads implementation where that wasn't the case. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx Thank you, it's what I need. You might also want to check the function log_tid() in server/log.c of httpd's trunk or 2.4. The thread id gets logged in the error log by default since 2.4, so that code converts it to a number. Regards, Rainer true, the ID is logged now, but is the function handling the thread id public? -- Massimo
Re: thread ID
On 05.03.2012 11:33, Massimo Manghi wrote: On 03/03/2012 07:04 PM, Rainer Jung wrote: On 02.03.2012 00:34, Sorin Manolache wrote: On 03/02/12 00:21, Ben Noordhuis wrote: On Thu, Mar 1, 2012 at 17:29,sorin.manola...@orange.com wrote: Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin What about apr_os_thread_current()? It returns a opaque value that's a pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to understand what that means. As a recovering standards lawyer I should probably point out that pthread_t is an opaque type that's not guaranteed to be convertible to a numeric value (or to anything, really). That said, I've never seen a pthreads implementation where that wasn't the case. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx Thank you, it's what I need. You might also want to check the function log_tid() in server/log.c of httpd's trunk or 2.4. The thread id gets logged in the error log by default since 2.4, so that code converts it to a number. Regards, Rainer true, the ID is logged now, but is the function handling the thread id public? not the function, but the source. See function log_tid() in server/log.c. Regards, Rainer
Re: thread ID
On 02.03.2012 00:34, Sorin Manolache wrote: On 03/02/12 00:21, Ben Noordhuis wrote: On Thu, Mar 1, 2012 at 17:29,sorin.manola...@orange.com wrote: Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin What about apr_os_thread_current()? It returns a opaque value that's a pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to understand what that means. As a recovering standards lawyer I should probably point out that pthread_t is an opaque type that's not guaranteed to be convertible to a numeric value (or to anything, really). That said, I've never seen a pthreads implementation where that wasn't the case. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx Thank you, it's what I need. You might also want to check the function log_tid() in server/log.c of httpd's trunk or 2.4. The thread id gets logged in the error log by default since 2.4, so that code converts it to a number. Regards, Rainer
Re: thread ID
On Thu, Mar 1, 2012 at 17:29, sorin.manola...@orange.com wrote: Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin What about apr_os_thread_current()? It returns a opaque value that's a pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to understand what that means. As a recovering standards lawyer I should probably point out that pthread_t is an opaque type that's not guaranteed to be convertible to a numeric value (or to anything, really). That said, I've never seen a pthreads implementation where that wasn't the case. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx
Re: thread ID
On 03/02/12 00:21, Ben Noordhuis wrote: On Thu, Mar 1, 2012 at 17:29,sorin.manola...@orange.com wrote: Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin What about apr_os_thread_current()? It returns a opaque value that's a pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to understand what that means. As a recovering standards lawyer I should probably point out that pthread_t is an opaque type that's not guaranteed to be convertible to a numeric value (or to anything, really). That said, I've never seen a pthreads implementation where that wasn't the case. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx Thank you, it's what I need. Sorin
thread ID
Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.
Re: mod_log_config: log thread id in hex
On Sat, Aug 27, 2005 at 11:12:24AM -0400, Jeff Trawick wrote:
%{tid}P gets you thread id in decimal now.
%{hextid}P would show it in hex using relatively new apr_sprintf()
format, added in 1.2.0.
Seems fine except that it introduces a softish dependency on apr =
1.2.0 which is not enforced by configure (which allows use of any apr
1.x).
Index: modules/loggers/mod_log_config.c
===
--- modules/loggers/mod_log_config.c (revision 240100)
+++ modules/loggers/mod_log_config.c (working copy)
@@ -650,13 +650,15 @@
if (*a == '\0' || !strcmp(a, pid)) {
return apr_psprintf(r-pool, % APR_PID_T_FMT, getpid());
}
-else if (!strcmp(a, tid)) {
+else if (!strcmp(a, tid) || !strcmp(a, hextid)) {
#if APR_HAS_THREADS
apr_os_thread_t tid = apr_os_thread_current();
#else
int tid = 0; /* APR will format 0 anyway but an arg is needed */
#endif
-return apr_psprintf(r-pool, %pT, tid);
+return apr_psprintf(r-pool,
+*a == 'h' ? %pt : %pT,
+tid);
}
/* bogus format */
return a;
Re: mod_log_config: log thread id in hex
On Tue, Aug 30, 2005 at 11:28:37AM +0100, Joe Orton wrote:
On Sat, Aug 27, 2005 at 11:12:24AM -0400, Jeff Trawick wrote:
%{tid}P gets you thread id in decimal now.
%{hextid}P would show it in hex using relatively new apr_sprintf()
format, added in 1.2.0.
Seems fine except that it introduces a softish dependency on apr =
1.2.0 which is not enforced by configure (which allows use of any apr
1.x).
Agreed. I'd guess we should make that conditional on having apr 1.2.0+.
With lower versions of APR, don't support that tag. -- justin
mod_log_config: log thread id in hex
%{tid}P gets you thread id in decimal now.
%{hextid}P would show it in hex using relatively new apr_sprintf()
format, added in 1.2.0.
Index: modules/loggers/mod_log_config.c
===
--- modules/loggers/mod_log_config.c(revision 240100)
+++ modules/loggers/mod_log_config.c(working copy)
@@ -650,13 +650,15 @@
if (*a == '\0' || !strcmp(a, pid)) {
return apr_psprintf(r-pool, % APR_PID_T_FMT, getpid());
}
-else if (!strcmp(a, tid)) {
+else if (!strcmp(a, tid) || !strcmp(a, hextid)) {
#if APR_HAS_THREADS
apr_os_thread_t tid = apr_os_thread_current();
#else
int tid = 0; /* APR will format 0 anyway but an arg is needed */
#endif
-return apr_psprintf(r-pool, %pT, tid);
+return apr_psprintf(r-pool,
+*a == 'h' ? %pt : %pT,
+tid);
}
/* bogus format */
return a;
[PATCH] displaying thread id in mod_status ExtendedStatus table
On 6/11/05, Jeff Trawick [EMAIL PROTECTED] wrote:
On 6/11/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
At 12:34 PM 6/11/2005, Jeff Trawick wrote:
I like the idea of toggling columns, I'd make it more like
columns=pid,tid,ss,m,req to allow for abbreviated displays.
columns= with column names like that works for me
columns=all displays everything (may change layout in the future)
default list for columns is whatever we display now
I like columns=* personally :) Less ambiguous if we decree all columns
can be toggled (especially if we allow modules to extend them).
Perhaps +/- syntax? Painful in code, but easier for the user
(?columns=+tid). +/- wouldn't reorder the columns from their
default, while explicit lists would?
No reordering of columns is possible with this patch.
The Srv column is always implicitly enabled.
'*' = all columns (need to escape it on shell command-line)
Bogus values for columns parameter are not reported.
No changes implemented for the no-table flavor of output (yet).
Something that is a bit painful is that APR doesn't have a way to
format a thread id in hex, and that is a useful format for correlation
with some third party logs. That should be resolved eventually so
that the thread id in hex (and perhaps the process id in hex too) can
be requested.
Step in the right direction?
Not usable since somebody is going to implement configurable field order soon?
Broken?
etc.
Thanks for any comments!
Index: modules/generators/mod_status.c
===
--- modules/generators/mod_status.c (revision 190183)
+++ modules/generators/mod_status.c (working copy)
@@ -71,6 +71,7 @@
#endif
#define APR_WANT_STRFUNC
#include apr_want.h
+#include apr_strings.h
#ifdef NEXT
#if (NX_CURRENT_COMPILER_RELEASE == 410)
@@ -190,6 +191,7 @@
#define STAT_OPT_REFRESH 0
#define STAT_OPT_NOTABLE 1
#define STAT_OPT_AUTO 2
+#define STAT_OPT_COLUMNS 4
struct stat_opt {
int id;
@@ -202,9 +204,103 @@
{STAT_OPT_REFRESH, refresh, Refresh},
{STAT_OPT_NOTABLE, notable, NULL},
{STAT_OPT_AUTO, auto, NULL},
+{STAT_OPT_COLUMNS, columns, NULL},
{STAT_OPT_END, NULL, NULL}
};
+#define COL_END -1
+#define COL_PID 1
+#define COL_TID 2
+#define COL_ACC 4
+#define COL_M 8
+#define COL_CPU 16
+#define COL_SS 32
+#define COL_REQ 64
+#define COL_CONN128
+#define COL_CHILD 256
+#define COL_SLOT512
+#define COL_CLIENT 1024
+#define COL_VHOST 2048
+#define COL_REQUEST4096
+#define COL_ALL 0x1FFF
+
+#ifdef HAVE_TIMES
+#define COL_DEFAULT (COL_PID|COL_ACC|COL_M|COL_CPU|COL_SS|COL_REQ|COL_CONN| \
+ COL_CHILD|COL_SLOT|COL_VHOST|COL_REQUEST)
+#else
+#define COL_DEFAULT (COL_PID|COL_ACC|COL_M|COL_SS|COL_REQ|COL_CONN| \
+ COL_CHILD|COL_SLOT|COL_VHOST|COL_REQUEST)
+#endif
+
+struct col_opt {
+int id;
+const char *label;
+const char *heading;
+};
+
+static const struct col_opt column_options[] =
+{
+{COL_PID,pid,PID},
+{COL_TID,tid,TID},
+{COL_ACC,acc,Acc},
+{COL_M, m, M},
+{COL_CPU,cpu,CPU},
+{COL_SS, ss, SS},
+{COL_REQ,req,Req},
+{COL_CONN, conn, Conn},
+{COL_CHILD, child, Child},
+{COL_SLOT, slot, Slot},
+{COL_CLIENT, client, Client},
+{COL_VHOST, vhost, VHost},
+{COL_REQUEST,request,Request},
+{COL_ALL,*, NULL},
+{COL_END,NULL, NULL}
+};
+
+static int get_columns(apr_pool_t *p, const char *c_arg)
+{
+char *arg;
+char *tok, *state;
+int columns = 0;
+
+if (ap_strchr_c(c_arg, '+') ||
+ap_strchr_c(c_arg, '-')) {
+columns = COL_DEFAULT;
+}
+
+arg = apr_pstrdup(p, c_arg);
+tok = apr_strtok(arg, ,=, state);
+while (tok) {
+int i = 0, plus = 0, minus = 0;
+if (*tok == '+') {
+plus = 1;
+++tok;
+}
+else if (*tok == '-') {
+minus = 1;
+++tok;
+}
+else {
+plus = 1;
+}
+while (column_options[i].id != COL_END) {
+if (!strcasecmp(tok, column_options[i].label)) {
+if (plus) {
+columns |= column_options[i].id;
+}
+else {
+columns = ~column_options[i].id;
+}
+break;
+}
+++i;
+}
+tok = apr_strtok(NULL, ,=, state);
+}
+
+return columns;
+}
+
static char status_flags[SERVER_NUM_STATUS];
static int status_handler(request_rec *r)
@@ -232,6 +328,7 @@
pid_t *pid_buffer, worker_pid;
clock_t tu, ts, tcu, tcs
Re: displaying thread id in mod_status ExtendedStatus table - how to request it?
On 6/9/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: At 05:03 AM 6/9/2005, Jeff Trawick wrote: Requre threadid in query argument to see this information? (/server-status/?notablethreadid or something like that) Or name the columns? Better yet, move to an XML output (?refresh=5display=xml) which any decent parser can tear apart, no matter how we change things in the future? I like the idea of toggling columns, I'd make it more like columns=pid,tid,ss,m,req to allow for abbreviated displays. columns= with column names like that works for me columns=all displays everything (may change layout in the future) default list for columns is whatever we display now modules need a flag to their status hook to know to implement xml (or omit if xml is required)... xml representation needed for everything else as well... or display=xml implies that you get just the extendedstatus table and absolutely nothing else One other thing, we should probably contemplate disallowing certain fields. E.g. someone who wanted server-status, but didn't want to leak pid/tid or remote IP information might want to lock out those fields from being returned. in due time, if someone is sufficiently itchy
Re: displaying thread id in mod_status ExtendedStatus table - how to request it?
At 12:34 PM 6/11/2005, Jeff Trawick wrote: I like the idea of toggling columns, I'd make it more like columns=pid,tid,ss,m,req to allow for abbreviated displays. columns= with column names like that works for me columns=all displays everything (may change layout in the future) default list for columns is whatever we display now I like columns=* personally :) Less ambiguous if we decree all columns can be toggled (especially if we allow modules to extend them). Perhaps +/- syntax? Painful in code, but easier for the user (?columns=+tid). +/- wouldn't reorder the columns from their default, while explicit lists would? modules need a flag to their status hook to know to implement xml (or omit if xml is required)... xml representation needed for everything else as well... or display=xml implies that you get just the extendedstatus table and absolutely nothing else I'd want the mode (xml v.s. html) to be toggled with a different option flag. The only reason for combining xml and columns would be some synthesized columns that require extra cpu, and the user knows exactly what they will use. I don't know of many computationally intensive columns, but if we later let this become extensible, I can see where that would become a potential issue. One other thing, we should probably contemplate disallowing certain fields. E.g. someone who wanted server-status, but didn't want to leak pid/tid or remote IP information might want to lock out those fields from being returned. in due time, if someone is sufficiently itchy I'll scratch :) If you have a first draft, I'll follow, otherwise I'd steal code from mod_autoindex to start with. Of course, this would be trivial with libapreq in the core, and would support using POST :) Bill
Re: displaying thread id in mod_status ExtendedStatus table - how to request it?
On 6/11/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: At 12:34 PM 6/11/2005, Jeff Trawick wrote: I like the idea of toggling columns, I'd make it more like columns=pid,tid,ss,m,req to allow for abbreviated displays. columns= with column names like that works for me columns=all displays everything (may change layout in the future) default list for columns is whatever we display now I like columns=* personally :) Less ambiguous if we decree all columns can be toggled (especially if we allow modules to extend them). Perhaps +/- syntax? Painful in code, but easier for the user (?columns=+tid). +/- wouldn't reorder the columns from their default, while explicit lists would? Cute, but brings with it more complexity of both code and documentation. I'll come up with something that handles the basic requirement and the rses of the world can take it from there ;)
displaying thread id in mod_status ExtendedStatus table - how to request it?
motivation: correlate stuck requests seen in mod_status display with entries in third-party logs which log pid+tid I assume that simply adding another column to the table will break existing scripts. Requre threadid in query argument to see this information? (/server-status/?notablethreadid or something like that) Have a query argument that tells mod_status to always spit out all available information? format may change if somebody adds a new column in the future (/server-status/?refresh=5showall)
Re: displaying thread id in mod_status ExtendedStatus table - how to request it?
At 05:03 AM 6/9/2005, Jeff Trawick wrote: motivation: correlate stuck requests seen in mod_status display with entries in third-party logs which log pid+tid +1, was bit by this issue myself a week ago(!) I assume that simply adding another column to the table will break existing scripts. Requre threadid in query argument to see this information? (/server-status/?notablethreadid or something like that) Have a query argument that tells mod_status to always spit out all available information? format may change if somebody adds a new column in the future (/server-status/?refresh=5showall) Or name the columns? Better yet, move to an XML output (?refresh=5display=xml) which any decent parser can tear apart, no matter how we change things in the future? I like the idea of toggling columns, I'd make it more like columns=pid,tid,ss,m,req to allow for abbreviated displays. One other thing, we should probably contemplate disallowing certain fields. E.g. someone who wanted server-status, but didn't want to leak pid/tid or remote IP information might want to lock out those fields from being returned. Bill
