time in threaded programs

J

JLeidel

All, I've been having an interesting issue in getting some `time`
functions to work within a threaded application. Essentially, all I'm
doing is retieving the local time from the main thread in order to
compare against a time offset of GMT.

So...

....
time_t cur_time = 0;
struct tm *my_time;
int rtn = 0;

time( &cur_time );
localtime_r( &cur_time, my_time );
....

segfaults on the `localtime_r` call.
compiled on suse linux using gcc 4.1.0; glibc 2.4-31.1
thread model is pthreads.

any thoughts??

cheers
john
 
W

Walter Roberson

All, I've been having an interesting issue in getting some `time`
functions to work within a threaded application.

Suggest that you ask in a threads programming newsgroup.
Threads are not part of the C language, so they are considered
off-topic in comp.lang.c .
 
M

Martin Golding

On Sun, 27 Jan 2008 20:20:24 -0800, JLeidel wrote:y
All, I've been having an interesting issue in getting some `time`
functions to work within a threaded application. Essentially, all I'm
doing is retieving the local time from the main thread in order to
compare against a time offset of GMT.

Were this a problem with threads or localtime_r, you would have
gotten better answers from comp.unix.programming. Even so, it
would have been useful to add the declaration of localtime_r
(adding which to your post would likely have triggered the
"oops" that you're looking for).

...
time_t cur_time = 0;
struct tm *my_time;
int rtn = 0;

time( &cur_time );
localtime_r( &cur_time, my_time );
...

segfaults on the `localtime_r` call.
compiled on suse linux using gcc 4.1.0; glibc 2.4-31.1 thread model is
pthreads.

any thoughts??

localtime_r appears to require a pointer to a struct tm. You appear
to be passing it an unitiialized pointer.

struct tm my_time;
....
localtime_r( &cur_time, &my_time );

Martin
 
K

Keith Thompson

JLeidel said:
All, I've been having an interesting issue in getting some `time`
functions to work within a threaded application. Essentially, all I'm
doing is retieving the local time from the main thread in order to
compare against a time offset of GMT.

So...

...
time_t cur_time = 0;
struct tm *my_time;
int rtn = 0;

time( &cur_time );
localtime_r( &cur_time, my_time );
...

segfaults on the `localtime_r` call.
compiled on suse linux using gcc 4.1.0; glibc 2.4-31.1
thread model is pthreads.

any thoughts??

If threading really were relevant to the problem, this probably
wouldn't be the place to ask about it. Standard C defines no support
for threading. There's a comp.programming.threads newsgroup.

If the semantics of localtime_r were relevant to the problem, this
probably wouldn't be the place to ask about it, since localtime_r is
not a standard C function (though localtime is).

But I notice that your variable my_time, as far as I can tell, has not
been initialized when you pass it to the localtime_r function.
Whatever localtime_r does, it's likely to use the values of its
parameters, which is going to invoke undefined behavior. You need to
assign some value to my_time before using it.

(I'm assuming my_time is uninitialized; I can't be certain because you
posted a code fragment rather than a complete program.)
 
C

CBFalconer

JLeidel said:
All, I've been having an interesting issue in getting some `time`
functions to work within a threaded application. Essentially,
all I'm doing is retieving the local time from the main thread in
order to compare against a time offset of GMT.

So...

...
time_t cur_time = 0;
struct tm *my_time;
int rtn = 0;

time( &cur_time );
localtime_r( &cur_time, my_time );
...

segfaults on the `localtime_r` call.

Bad call. From N869:

7.23.3.4 The localtime function

Synopsis
[#1]
#include <time.h>
struct tm *localtime(const time_t *timer);

Description

[#2] The localtime function converts the calendar time
pointed to by timer into a broken-down time, expressed as
local time.

Returns

[#3] The localtime function returns a pointer to the broken-
down time, or a null pointer if the specified time cannot be
converted to local time.
 
I

Ian Collins

CBFalconer said:
JLeidel said:
time( &cur_time );
localtime_r( &cur_time, my_time );
...

segfaults on the `localtime_r` call.

Bad call. From N869:
Why?

7.23.3.4 The localtime function

Synopsis
[#1]
#include <time.h>
struct tm *localtime(const time_t *timer);

Returns

[#3] The localtime function returns a pointer to the broken-
down time, or a null pointer if the specified time cannot be
converted to local time.
Which is why it is not recommended in threaded code, there is nothing to
say whether the pointer returned points to a shared or unique
(per-thread) object, hence the addition of the _r functions in a certain
unmentionable standard.
 
M

Martin Ambuhl

JLeidel said:
All, I've been having an interesting issue in getting some `time`
functions to work within a threaded application. Essentially, all I'm
doing is retieving the local time from the main thread in order to
compare against a time offset of GMT.
time_t cur_time = 0;
struct tm *my_time;
int rtn = 0;
time( &cur_time );
localtime_r( &cur_time, my_time );
segfaults on the `localtime_r` call.
compiled on suse linux using gcc 4.1.0; glibc 2.4-31.1
thread model is pthreads.

#include <time.h>
#include <stdio.h>

int main(void)
{
time_t cur_time = 0;
struct tm *my_time;

time(&cur_time);

/* There is no way to tell if the OP's
"localtime_r( &cur_time, my_time );"
is right, since localtime_r is not
a standard C function. It is very
suspicious looking, since the indeterminate
value of the pointer my_time is passed.
'my_time' does not point to any allocated
space, and so this argument must be completely
useless.

Below is not the way I would normally use
localtime, preferring to copy the pointed
to structure to an actually allocated one.
Still, it will work, while the odds are
heavily against the OP's line doing anything
useful.
*/
my_time = localtime(&cur_time);
printf("ctime(&cur_time) is %s"
"asctime(my_time) is %s.",
ctime(&cur_time), asctime(my_time));
return 0;
}


[output]
ctime(&cur_time) is Mon Jan 28 02:28:50 2008
asctime(my_time) is Mon Jan 28 02:28:50 2008.
 
C

CBFalconer

Randy said:
Ian Collins wrote

Probably due to him jumping the gun again and not seeing the _r part.

True. However I don't recall that localtime_r code was shown.
 
R

Randy Howard

True. However I don't recall that localtime_r code was shown.

It's in the article you quoted. And there it is again, for your
convenience. Just look up ^^^
 
J

Joachim Schmitz

Randy said:
It's in the article you quoted. And there it is again, for your
convenience. Just look up ^^^
No, it's not. The call to localtime_r is shown, but not it's code.

Bye, Jojo
 
R

Randy Howard

No, it's not. The call to localtime_r is shown, but not it's code.

*sigh*

It was code /using/ localtime_r. If you want to see what the
implementation for that looks like, fine, but that has nothing to do
with what happened earlier in this thread.
 
M

Martin Ambuhl

Randy said:
It's in the article you quoted. And there it is again, for your
convenience. Just look up ^^^

It's time you learned to read. Nowhere did CDFalconer suggest there
were no references to localtime_r. He said that he did not recall that
the localtime_r _code_ was shown. Since localtime_r is not part of
standard C, any questions about it require that its _code_ be shown or
we can't known what it is or does. Worse, there is not even a prototype
shown, so we can't even know what the arguments ought to be.
 
K

Keith Thompson

Martin Ambuhl said:
It's time you learned to read. Nowhere did CDFalconer suggest there
were no references to localtime_r. He said that he did not recall
that the localtime_r _code_ was shown. Since localtime_r is not part
of standard C, any questions about it require that its _code_ be shown
or we can't known what it is or does. Worse, there is not even a
prototype shown, so we can't even know what the arguments ought to be.

True, but it's safe to assume that the value of an uninitialized
variable is not a valid argument. In the call shown in the posted
code fragment, one of the arguments was an apparently uninitalized
variable; just evaluating it invokes UB even before the call. (In
practice, bad things are likely to happen inside localtime_r() when it
tries to use the parameter.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top