mariadb/mysys/my_getsystime.c

183 lines
5 KiB
C
Raw Normal View History

/* Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.
2004-03-02 22:21:12 +01:00
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.
2004-03-02 22:21:12 +01:00
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA */
2004-03-02 22:21:12 +01:00
/* get time since epoc in 100 nanosec units */
/* thus to get the current time we should use the system function
with the highest possible resolution */
/*
TODO: in functions my_micro_time() and my_micro_time_and_time() there
exists some common code that should be merged into a function.
*/
#include "mysys_priv.h"
#include "my_static.h"
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
/**
Get high-resolution time.
@remark For windows platforms we need the frequency value of
the CPU. This is initialized in my_init.c through
QueryPerformanceFrequency(). If the Windows platform
doesn't support QueryPerformanceFrequency(), zero is
returned.
@retval current high-resolution time.
*/
2004-03-02 22:21:12 +01:00
ulonglong my_getsystime()
{
#ifdef HAVE_CLOCK_GETTIME
struct timespec tp;
clock_gettime(CLOCK_REALTIME, &tp);
return (ulonglong)tp.tv_sec*10000000+(ulonglong)tp.tv_nsec/100;
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
#elif defined(_WIN32)
LARGE_INTEGER t_cnt;
if (query_performance_frequency)
{
2004-05-05 10:54:11 -03:00
QueryPerformanceCounter(&t_cnt);
return ((t_cnt.QuadPart / query_performance_frequency * 10000000) +
2008-02-18 16:47:00 +02:00
((t_cnt.QuadPart % query_performance_frequency) * 10000000 /
query_performance_frequency) + query_performance_offset);
}
return 0;
2004-03-02 22:21:12 +01:00
#else
/* TODO: check for other possibilities for hi-res timestamping */
struct timeval tv;
gettimeofday(&tv,NULL);
return (ulonglong)tv.tv_sec*10000000+(ulonglong)tv.tv_usec*10;
#endif
}
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
/**
Return current time.
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@param flags If MY_WME is set, write error if time call fails.
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@retval current time.
*/
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
time_t my_time(myf flags)
{
time_t t;
/* The following loop is here beacuse time() may fail on some systems */
while ((t= time(0)) == (time_t) -1)
{
if (flags & MY_WME)
fprintf(stderr, "%s: Warning: time() call failed\n", my_progname);
}
return t;
}
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
/**
Return time in microseconds.
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@remark This function is to be used to measure performance in
micro seconds. As it's not defined whats the start time
for the clock, this function us only useful to measure
time between two moments.
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@retval Value in microseconds from some undefined point in time.
*/
ulonglong my_micro_time()
{
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
#ifdef _WIN32
2008-02-18 16:47:00 +02:00
ulonglong newtime;
GetSystemTimeAsFileTime((FILETIME*)&newtime);
return (newtime/10);
#else
2008-02-18 16:47:00 +02:00
ulonglong newtime;
struct timeval t;
/*
The following loop is here because gettimeofday may fail on some systems
*/
while (gettimeofday(&t, NULL) != 0)
{}
newtime= (ulonglong)t.tv_sec * 1000000 + t.tv_usec;
return newtime;
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
#endif
}
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
/**
Return time in seconds and timer in microseconds (not different start!)
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@param time_arg Will be set to seconds since epoch.
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@remark This function is to be useful when we need both the time and
microtime. For example in MySQL this is used to get the query
time start of a query and to measure the time of a query (for
the slow query log)
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@remark The time source is the same as for my_micro_time(), meaning
that time values returned by both functions can be intermixed
in meaningful ways (i.e. for comparison purposes).
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@retval Value in microseconds from some undefined point in time.
*/
/* Difference between GetSystemTimeAsFileTime() and now() */
#define OFFSET_TO_EPOCH 116444736000000000ULL
ulonglong my_micro_time_and_time(time_t *time_arg)
{
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
#ifdef _WIN32
2008-02-18 16:47:00 +02:00
ulonglong newtime;
GetSystemTimeAsFileTime((FILETIME*)&newtime);
*time_arg= (time_t) ((newtime - OFFSET_TO_EPOCH) / 10000000);
2008-02-18 16:47:00 +02:00
return (newtime/10);
#else
2008-02-18 16:47:00 +02:00
ulonglong newtime;
struct timeval t;
/*
The following loop is here because gettimeofday may fail on some systems
*/
while (gettimeofday(&t, NULL) != 0)
{}
*time_arg= t.tv_sec;
newtime= (ulonglong)t.tv_sec * 1000000 + t.tv_usec;
return newtime;
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
#endif
}
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
/**
Returns current time.
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@param microtime Value from very recent my_micro_time().
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@remark This function returns the current time. The microtime argument
is only used if my_micro_time() uses a function that can safely
be converted to the current time.
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
@retval current time.
*/
time_t my_time_possible_from_micro(ulonglong microtime __attribute__((unused)))
{
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
#ifdef _WIN32
time_t t;
while ((t= time(0)) == (time_t) -1)
{}
return t;
#else
return (time_t) (microtime / 1000000);
Bug#42054: SELECT CURDATE() is returning bad value The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance.
2011-01-12 18:36:39 -02:00
#endif
}