Hello,

I would like to add NowUTC to SysUtils as we have already discussed previously. I think that the need for adding this should be of common knowledge for all after the long discussions about Now, and I understand that this was agreed upon, although surely we can discuss again.

So ok, now the problem starts. I have never added a new routine to the RTL before, so I am totally lost at what exactly to do, because there is a pletora of platforms there and I have implementations only for the platforms which I use, which are Windows and UNIX (I think it should work in all of them)

So what is done in these cases? Should I give some time for maintainers of those platforms to come up with implementations?

And if they don't? Just add a stub returning Now or something like that?

Adding a GetTickCount routine would also be good. Lazarus has this:

function GetTickCount64: QWord;

But maybe in the RTL it should have a different name to avoid conflicts with the Windows unit... but which name?

thanks,

fpGetTickCount, fpGetTickCount64 ?

zeljko

On Fri, December 9, 2011 09:23, Felipe Monteiro de Carvalho wrote:

Hi,

Preferably add a common dummy version (based on Now as you suggested and possibly environment variable TZ because tools like Zip/Unzip provide this kind of user controlled support for timezone calculations even for platforms not providing such functionality at API level) for platforms without proper support (e.g. GO32v2) and include it under $IFNDEF HAS_UTCNOW which is then defined at the platform specific implementations. See sysutils.inc for existing examples.

Is it preferred to return ticks (dependent on various stuff), or something like GetMsCount (as already existing in unit Dos)?

Tomas

In our previous episode, Felipe Monteiro de Carvalho said:

I thought that discussion had established that a timezone based on fpgettimeofday is not reliable on Linux? Yet, I see it in this patch?

Marco van de Voort wrote

I thought that discussion had established that a timezone based on fpgettimeofday is not reliable on Linux? Yet, I see it in this patch?

In my tests it worked. What do you propose instead?

There are 2 ways:
1. Place an empty routine in all platform sysutils units.

2. Placy a dummy routine which returns 'now' in sysutils.inc
{$IFNDEF FPC_HAS_NOWUTC}
function NowUTC : TDateTime;
begin
   Result:=Now;
end;
{$ENDIF}

Platform maintainers then add a {$DEFINE FPC_HAS_NOWUTC} to the platform unit as soon as they implement it, and their definition will be used instead.

I don't think it needs a different name, GetTickCount is OK. Why would you need that ? Units are namespaces, after all.

Michael.

In our previous episode, Felipe Monteiro de Carvalho said:

Not adding routines to crossplatform interfaces till it is demonstrated it is properly implementable on all platforms. (or at least *nix, OSX and Windows, with *nix having some overlap with OS X)

Crossplatform functions which are only stubs on some platforms are useless and should not be added.

I don't see the problem.
As far as I can see, NowUTC should simply return the kernel time and not perform the shift to local time (which Now() should do).

Surely this works on all platforms ?

Michael.

.
.

...working with UTC natively. ;-)

Tomas

In our previous episode, Michael Van Canneyt said:

IIRC the discussion stated that maintaining timezones in the kernel on linux is deprecated?

what does that have to do with the issue ?

The linux kernel returns UTC time, it always has. Now() converts this to local time. (as does libc). All NowUTC needs to do is return the kernel time.

Michael.

Michael Van Canneyt wrote

The linux kernel returns UTC time, it always has. Now() converts this to local time. (as does libc). All NowUTC needs to do is return the kernel time.

It should only be called NowUTC if it is defined as always returning UTC on all platforms.

Jonas

Obviously assuming that something like that is possible on a certain platform at all (GO32v2 not having the TZ environment variable defined will simply never be able to provide UTC time; in fact, the same applies for OS/2 / eCS too).

Tomas

2011/12/9 Tomas Hajny :

Is it preferred to return ticks (dependent on various stuff), or something like GetMsCount (as already existing in unit Dos)?

I would like to define it like this:

"FPGetTickCount returns the amount of ticks since an unspecified initial time. This initial time is unknown, but is fixed for the entire duration of the application. Ticks are time intervals and all of them have the same duration, but their exact meaning in terms of real world units like milliseconds is unspecified. FPGetTickCount is not affected by timezones and also not by the user changing the system clock."

So it matches Windows.GetTickCount well but still is flexible enough to be implemented in other platforms.

I don't think it needs a different name, GetTickCount is OK. Why would you need that ? Units are namespaces, after all.

Yes, but legacy applications with both SysUtils and Windows in the uses clause might suddently start using the SysUtils routine ... In Lazarus we tried something like that and we got a couple of problems very fast by units which suddenly started using the new GetTickCount ... it had to do with our GetTickCount returning 64-bits and the Windows one returning 32-bits... so that's why I would recommend FPGetTickCount: QWord

In our previous episode, Michael Van Canneyt said:

Could be. I thought that was the old situation, but assumed now that timezone is an userland thing, it returned the HW clock. But I assume it needs some form of timezone too for certain protocols.

So who maintains the difference between hardware clock and UTC for the kernel's benefit then, and where is that maintained?

What if the PC is polling a time server or similar ? IMHO FPGetTickCount should not be affected by such interference. This rules out using OS time API calls.

-Michael

Userland (=libc) tools, hwclock and the like ?

Michael.

Obviously :)

Michael.

OK.

Michael.

I do not think the Go32V2 environment needs to be considered. It stems from an age where the difference in timezones was irrelevant on a PC.

There are much more functions that perform strangely - if at all - in go32V2. It doesn't even have threading multi-tasking or multi-user support. Nonetheless we introduced already lots of functions that assume this, and no-one so much as squeaked then.
For a function as NowUTC I do not think we should start pulling this argument.

As far as I know, Windows and all Unix-like OSes support returning UTC. I know nothing about OS/2-eCS, but the same arguments as for Go32V2 apply as far as I am concerned. If all these platforms can guarantee returning correct UTC time, I do not see why we would not introduce it.

Michael.

Michael Van Canneyt wrote

I know nothing about OS/2-eCS, but the same arguments as for Go32V2 apply as far as I am concerned. If all these platforms can guarantee returning correct UTC time, I do not see why we would not introduce it.

Afaik the original point was that some people were interested in some kind of timestamp that does not jump around (except possibly when overflowing). I don't think anyone particularly needed "the time in UTC". Therefore, something like FPGetTickCount seems much more appropriate than NowUTC, and it also solves the problem that some targets may not support returning the time in UTC.

Jonas

In our previous episode, Jonas Maebe said:

Agree fully.

In our previous episode, Michael Van Canneyt said:

Any non-kernel solutions that might do own calculations yes.

Note that I'm asking because sooner or later I'll have to map whatever *nix implementation Felipe comes up with to FreeBSD.

Jonas Maebe wrote

Afaik the original point was that some people were interested in some kind of timestamp that does not jump around (except possibly when overflowing). I don't think anyone particularly needed "the time in UTC".

I disagree. I think that getting the current time in UTC is basic enough to be awarded a routine and has merit on its own, even disregarding it's usage in profilers.

Not to mention that FPGetTickCount returns it's value in an unspecified time unit, what if I want a less disturbed time in miliseconds? A time which doesn't require reading a file to be obtained? (like the perfect Now() should do in UNIX )

something like FPGetTickCount seems much more appropriate than NowUTC, and

I think that they do not exclude one another.

it also solves the problem that some targets may not support returning the time in UTC.

I think that Michael already exposed more then enough the holes in this argument.

On Fri, Dec 9, 2011 at 2:00 PM, Jonas Maebe wrote: > Afaik the original point was that some people were interested in some kind > of timestamp that does not jump around (except possibly when overflowing). I > don't think anyone particularly needed "the time in UTC".

Use case example: You need to store the current time in UTC in a database.

aha, the implementation of NowUTC is a bit more complex then I thought =D

I tested it in Mac OS X and in a linux in a virtual machine and it worked perfectly, but now I tested in a linux machine and it failed ... and I just found that in my system I have:

/etc/sysconfig/clock

UTC=false <-- problem here
ARC=false
ZONE=Poland

So NowUTC is not really necessarily immune to the lookup of files in Linux.

But I still maintain that it is a very useful routine.

Hello,

How can one call clock_gettime ? I couldn't find a fp prefixed routine for it ...

IMO the dummy routine should return some error value, e.g. zero or NaN, that makes it clear to the user that something's wrong with that function. Else nobody will ever notice and update the implementation.

DoDi

The description of Felipe mathes Windows' GetTickCount (number of milliseconds since system start) and Linux' MONOTONIC_RAW time (or however it is called exactly). So I don't see why this should rule out OS time API calls...

Regards,
Sven

You might need to add it then if it does not exist... (I don't know what the rules are for adding a new function for a syscall though)

Regards,
Sven

Felipe Monteiro de Carvalho wrote

Hello, How can one call clock_gettime ? I couldn't find a fp prefixed routine for it ...

I have this on my todo list.

The main problem is that I don't know yet if it is Linux-specific or Posix. That will determine which unit it will be added to. Maybe Marco knows more ?

Michael.

In our previous episode, Felipe Monteiro de Carvalho said:

Nine times out of ten you solve that server side, not client side.

In our previous episode, Michael Van Canneyt said:

No idea.

But maybe IMHO this kind of stuff should remain out of sysutils, certainly now it is not entirely clear, and people are still searching for solutions.

Sysutils should only contain stuff that is absolutely certain to be portable.

And if it is outside of sysutils, it can also link to libc on *nix.

So IMHO, stuff it in fcl-base as "timerutils" or so, let it link to libc, basta. I don't see the need for it in the core subset, and neither the need to do it all manually.

Michael Van Canneyt wrote

The main problem is that I don't know yet if it is Linux-specific or Posix. That will determine which unit it will be added to. Maybe Marco knows more ?

Wow, timing in UNIX is such a mess, it seams that clock_gettime doesn't exist in Mac OS X =(

http://juliusdavies.ca/posix_clocks/clock_realtime_macosx_faq.html

http://www.tin.org/bin/man.cgi?section=3&topic=clock_gettime

AVAILABILITY
On POSIX systems on which these functions are available, the symbol _POSIX_TIMERS is defined in <unistd.h> to a value greater than 0. The symbols _POSIX_MONOTONIC_CLOCK, _POSIX_CPUTIME, _POSIX_THREAD_CPUTIME indicate that CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID are available. (See also sysconf(3).)

But it exists in FreeBSD:

http://www.unix.com/man-page/FreeBSD/2/CLOCK_GETTIME/

In our previous episode, Felipe Monteiro de Carvalho said: [ Charset ISO-8859-1 unsupported, converting... ]

Here (FC14) contains:

# The time zone of the system is defined by the contents of /etc/localtime. # This file is only for evaluation by system-config-date, do not rely on its # contents elsewhere.
ZONE="Europe/Amsterdam"

and /etc/localtime is binary

So be very careful extrapolating "a" linux distro to "linux".

And FreeBSD doesn't have /etc/sysconfig at all.

Possibly, but that's a different discussion than the one you referred to in your original mail.

He did not expose any holes in any argument. He simply said that Go32v2 and OS/2 can be ignored as far as any potential implementation problems are concerned because Go32v2 and to a (much) lesser extent OS/ 2 do not support various features. I strongly disagree about the OS/2 part because its target support is still actively maintained, so the least courtesy we can do is to try to accomodate it rather than simply upfront state "if it doesn't work for your target, tough luck".

Jonas

The man page says it's POSIX:

http://www.kernel.org/doc/man-pages/online/pages/man2/clock_gettime.2.html#CONFORMING_TO

Henry

That's not the question.

clock_gettime is a linux kernel call. No-one is proposing to add it to sysutils.

The question is whether clock_gettime is POSIX, and if BSD has it. The linux man page seems to say it is POSIX 2001. My question is if BSD has it.

If so, it can be added to baseunix/unix, instead of linux.

Michael.

He writes: " Ticks are time intervals and all of them have the same duration "

So the counting is not allowed to stop or to jump forward in case a time server access by daemon changing the system time is not allowed to interfere in any way.

So I suppose "GetTickCount (number of milliseconds since system start)" would be OK, but MONOTONIC_RAW time does not _sound_ correct.

On Linux, "get_jiffies_64()" seems to be a decent Kernel call.

-Michael

Marco van de Voort wrote

But maybe IMHO this kind of stuff should remain out of sysutils, certainly now it is not entirely clear, and people are still searching for solutions.

NowUTC is not any less portable then Now in relevant platforms.

My question about clock_gettime was for FPGetTickCount, which indeed is still far from having a proper implementation.

So IMHO, stuff it in fcl-base as "timerutils" or so, let it link to libc, basta. I don't see the need for it in the core subset, and neither the need to do it all manually.

This would be useless, both NowUTC and GetTickCount64 are already in lazutils, so I don't see any benefit in moving them to anything in the FCL.

But I saw a benefit in moving NowUTC to the RTL because it shares a lot of code with Now, they are nearly identical, so we could avoid duplicated code and because it is a very basic routine.

it is - i am using it since years ...

http://www.freebsd.org/cgi/man.cgi?query=clock_gettime

helmut

No, MONOTONIC_RAW is introduced in 2.6.26 afair, so it won't run on older kernels.

zeljko

zeljko wrote

No, MONOTONIC_RAW is introduced in 2.6.26 afair, so it won't run on older kernels.

My ideas was: Check if MONOTONIC_RAW is available, if yes, use it, if not, fallback to MONOTONIC which is a close approximation, not perfect, but the best one can do for old kernels.

I.e. means to quickly build time *differences*, for performance and progress display. That's almost the only use for GetTickCount, and for that purpose the underlying source must be monotonic.

I don't think anyone particularly needed "the time in UTC". Therefore, something like FPGetTickCount seems much more appropriate than NowUTC, and it also solves the problem that some targets may not support returning the time in UTC.

In contrast to Now with local time (with DST and timezones), NowUTC should return monotonic, platform independent and comparable absolute time values.

When some (very old) platforms don't support UTC, we could at least implement something like GetTimeStamp, that returns absolute time values at least for the current platform. These values should be usable as unique (monontonic) time stamps in e.g. log files.

DoDi

In our previous episode, Michael Van Canneyt said:

If we decide to use it via libc, we might not have to add it as a syscall.

The question is whether clock_gettime is POSIX, and if BSD has it. The linux man page seems to say it is POSIX 2001. My question is if BSD has it.

FreeBSD has it. But OS X hasn't it seems, not even in recent versions.

Solaris seems to have it (libc call (3) though).
Can't check openbsd or Haiku easily.

I don't see any loss of the OS/2 FPC community if 1 routine won't work for them, supposing it is really impossible to implement it there.

Will things be better for the OS/2 FPC community if instead of only OS/2 not having NowUTC noone has?

And to put things into their real perspective, what is the proportion of OS/2 users in the FPC community? From source forge I'd say 0,005% or less

Marco van de Voort wrote

FreeBSD has it. But OS X hasn't it seems, not even in recent versions.

Yes, there's many posts and arguing from OSX developers about this.

zeljko

.
.

Is this "time fixed for the entire duration of the application" available on all platforms (especially considering the HW point of view now)?

Wouldn't the use be limited by the fact that the length of time is not specified at all? You cannot use it for measuring of time intervals any longer then, e.g. stuff like check if the period of time between two events was at least X (that was the reason for implementing Dos.GetMsCount some time ago) or measuring that certain procedure took Y. There's also a risk that users will start using it that way anyway based on assumptions from x86 is probably the worst thing resulting in unportable code.

Tomas

In our previous episode, Marco van de Voort said:

Let's not forget btw that it is not just a matter of the call, the constants matter too.

E.g. constants for FreeBSD: (even with clock_gettime, it is not guaranteed that all clock varieties are supported. Can't get that from the manpages).

So while monotonic exists, it seems to be in seconds. Maybe the precise/fast freebsd specific ones have low granularity.

From manpage:

The clock_id argument can be one of five values: CLOCK_REALTIME for time that increments as a wall clock should, CLOCK_MONOTONIC which increments
in SI seconds, CLOCK_UPTIME which starts at zero when the kernel boots and increments monotonically in SI seconds while the machine is running,
CLOCK_VIRTUAL for time that increments only when the CPU is running in user mode on behalf of the calling process, or CLOCK_PROF for time that increments when the CPU is running in user or kernel mode.

and header:

#define CLOCK_REALTIME 0
#ifdef __BSD_VISIBLE
#define CLOCK_VIRTUAL 1
#define CLOCK_PROF 2
#endif
#define CLOCK_MONOTONIC 4
#define CLOCK_UPTIME 5 /* FreeBSD-specific. */ #define CLOCK_UPTIME_PRECISE 7 /* FreeBSD-specific. */ #define CLOCK_UPTIME_FAST 8 /* FreeBSD-specific. */ #define CLOCK_REALTIME_PRECISE 9 /* FreeBSD-specific. */ #define CLOCK_REALTIME_FAST 10 /* FreeBSD-specific. */ #define CLOCK_MONOTONIC_PRECISE 11 /* FreeBSD-specific. */ #define CLOCK_MONOTONIC_FAST 12 /* FreeBSD-specific. */ #define CLOCK_SECOND 13 /* FreeBSD-specific. */ #define CLOCK_THREAD_CPUTIME_ID 14
#endif /* !defined(CLOCK_REALTIME) && __POSIX_VISIBLE >= 200112 */

Marco van de Voort wrote

FreeBSD has it.  But OS X hasn't it seems, not even in recent versions.

I'm not sure if Mac OS X has it, but it doesn't work (returns failure or something) or if it doesn't have
Felipe Monteiro de Carvalho

That was not meant as argument against introducing NowUTC, but rather just a comment that your stated goal of providing UTC everywhere may not be met. I don't have any objections.

Tomas

That sounds as if you think a syscall is a bad thing ? In each case, it's not really relevant.

This is not a real argument;
The constants or types for many other posixy-functions are system dependent;
we introduced them anyway.

Well, if OS-X does not have it, we can't really say it is POSIX for our purposes, so then it goes to the linux unit. It's as simple as that.

Unless you have arguments for putting it in (base)unix anyway.

Michael.

2011/12/9 Tomas Hajny :

Wouldn't the use be limited by the fact that the length of time is not specified at all?

Yes, this limits the usefulness of the routine. I added it to simplify the implementation and match Windows.GetTickCount64 and MONOTONIC_RAW, but if someone can come up with a better implementation which supports a specified length of time it would be ideal.

In our previous episode, Michael Van Canneyt said:

For borderline functionality ? yes I do.

It is something else to avoid the core system getting to entangled with libc, but that doesn't mean I want to reimplement all libc of all unixy platforms and maintain that.

If it is not necessary, IMHO we shouldn't add it to core units. Including baseunix.

The problem is that you don't want clock_gettime(), but clock_gettime(MONOTONIC_RAW).

The constant is not something where you merely have to search the relevant values for the various OS, and have one or two that are unsupported, but the core reason to add it is not portable. At least if I understood everything correctly.

There is a fat chance that the whole finely grained monotonic stuff is highly OS specific. But maybe Helmut can weigh in on that again.

Well, if OS-X does not have it, we can't really say it is POSIX for our purposes, so then it goes to the linux unit. It's as simple as that. Unless you have arguments for putting it in (base)unix anyway.

No. Better put it in target specific units, so that people know they are messing with functions with portability issues.

Hola :-) I didn't say we should not accomodate it.

I did say that *the decision* to introduce it should not depend on some specific older platforms not being able to support it, since this is true for other calls as well, and they were introduced nonetheless.

If we decide to put it in, we should help Tomas finding an implementation method for OS/2. This is understood.

Michael.

Well, if OS-X does not have it, we can't really say it is POSIX for our purposes, so then it goes to the linux unit. It's as simple as that.

Only if you discriminate BSD systems :-) - Many professional vendors use some sort of BSD in their products,
and some fpc.

Freebsd, Netbsd, Openbsd, and Linux has it.
For OSX there is a substitution:
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x

helmut

No, this is common practice in the RTL so there's no need to change that.

Regards,
Sven

No problem.
I will do it so, I was leaning to this anyway based on the mails of Zeljko some weeks back where the OSX issue was already touched upon.

I just wanted to know the POSIX situation first, and now that's cleared up.

Michael.

My comment was less for which timer type we should support, but more to have a argument for what Felipe said.

Regards,
Sven

I haven't found an entry for "MONOTONIC_RAW" (my system's manpage has one, but I'm currently at work), but for MONOTONIC:

CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since some unspecified starting point.

So even if a deamon plays around with the time the MONOTONIC clock should not be affected. That's the basic idea of the MONOTONIC clocks.

On Linux, "get_jiffies_64()" seems to be a decent Kernel call.

I don't know that, so I can't comment here.

Regards,
Sven

Marco van de Voort wrote

It is something else to avoid the core system getting to entangled with libc, but that doesn't mean I want to reimplement all libc of all unixy platforms and maintain that.

Why do we provide our own memory manager anyway? Just kill it and ship cmem only.

fcl-image? kill it in favor of the bindings to ImageMagick.

WriteLn? The platform probably already has printf...

The problem is that you don't want clock_gettime(), but clock_gettime(MONOTONIC_RAW).

Not true, I would like to have the general routine. At least CLOCK_MONOTONIC_RAW, CLOCK_MONOTINIC and CLOCK_REALTIME are constants I already know I'd like to test. But there may be more.

Your statements (except the fcl-image one) contradict Marco's statement "to avoid the core system getting to entangled with libc".

Regards,
Sven

In our previous episode, Michael Van Canneyt said:

Btw, you'll need clock_getres too, to get the granularity of the relevant timer. (and anything using these, should really use that function)

Still I think it is better to put this in a package, and link to libc for them, instead of pulling this into the core. (iow, like the users package)

Well, you'll have to convince Marco.
But I think it's that time of the month, when he's hard to convince, just for the fun of discussion :)

But till you do convince him, I'll put it in the linux unit, and Marco can put it in a *BSD specific unit.

That's what these units are for.

Michael.

In our previous episode, Felipe Monteiro de Carvalho said:

Because any program needs a memory manager, and we decided that the core RTL should run without libc. (and I still stand by that decision then, and I'm open to discussion wrt the current situation)

Just kill it and ship cmem only.

No need to apply reductio ad absurdum. There are already precedents enough, like users, cnetdb and all other C lib headers in pacakges/

No. Monotonic_RAW is linux specific, and maybe not even on all archs.

And while the other two exist more widely, there are warnings about granularity and not assuming anything about their granularity (which might be one full second)

I already know I'd like to test. But there may be more.

IMHO that should have been done in the first place. First research and find a workable, portable way, and only then put it up for inclusion.

No, that's what the Linux unit is for: provide access to linux kernel calls not specified in POSIX. Linking to libc is not an option, I leave that to the (hereto imaginary) implementors of a glibc() unit.

I plan to add inotify() calls there as well (in separate commits, though).

Michael.

You can't use this in userspace.

Henry

Thanks, but don't worry, I didn't take personally. ;-) I know the proper solution for both GO32v2 and OS/2 (and probably also other platforms not providing native support of timezone handling). As mentioned previously, this solution is based on parsing the TZ environment variable (see e.g. http://www.scribd.com/doc/70722660/37/The-TZ-Environment-Variable including the notes about the "alternative format used for OS/2" - and actually necessary for DOS / GO32v2 too).

The only trouble (and reason of my original comment) is that the system doesn't enforce existence or validity of this environment variable - it's merely a user setting. If it doesn't exist, the implementation needs to assume that local time = UTC.

Tomas

MONOTONIC can still be affected by NTP, MONOTONIC_RAW can't.

Henry

In our previous episode, Michael Van Canneyt said:

Strange. I had the same feeling. Something random functionality HAD to be put in, damn the consequences or counter arguments.

I don't understand. Why link to libc for these? They are syscalls, if I'm not missing something.

Henry

:-) Boy, I am happy that I dont need to convince anybody anymore.

@granularity:
The granularity is not only OS dependend but hardware dependend. In FreeBSD you have the granularity if you have a hardware high precision timer.
This can be queried via sysctls, i assume this is handled in other os's similar.
For our software we have to handle this target and hardware specific(!). But we use server appliance hardware with freebsd and fpc software for our products - and that is somewhat exotic.

@speed
The constants influence highly the time needed for the call, so in general you want to know what for you need the time base. Some background:
http://phk.freebsd.dk/pubs/timecounter.pdf

@portable NowUTC
I would have been happy if FPC had provided me the super ultra fast, high precise and platform independend timer routine, But i would not have been happy for long - As fpc simply can't read ones mind and be better then the underlying hardware/os. If i recall right we use 4 different timing mechanism throughout our source because we need them.

So if FPC provides a generic higher precise timing routine is should be documented that it is a starting point only.

But of course it would be nice for every day usage to have a cross platform call.

helmut

In our previous episode, Henry Vermaak said:

> them, instead of pulling this into the core. (iow, like the users package) I don't understand. Why link to libc for these? They are syscalls, if

Are they? On any OS and arch that calls itself posix or unix?

Or maybe, the question should be the opposite, why not? Why shouldn't such peripheral calls NOT be taken from libc?

$

Not quite.

If we're talking about clock_gettime, that was on my agenda since Zeljko pointed out their existence, as I stated in my initial post: "it is on my todo list".

It is a linux kernel call, and therefor earns its place at least in the linux unit, it is the purpose of that unit.

Concerning Felipe's functions NowUTC and gettickcount or whatever in sysutils: I am generally neutral, slightly in favour, but mostly just participating in the discussion;

Much like you, I suspect, with the possible difference that you are slightly (or much) against :-)

Michael.

Henry Vermaak wrote

> > On Linux, "get_jiffies_64()" seems to be a decent Kernel call.

Rechecking, I found that you are correct, this is a Kernel-internal call.

On a quick search, I in fact did not find a userland api call for getting the current jiffie value (but I seem to remember that I did use it some years ago in C).

-Michael

Ok, also I forgot to mention that MONOTNIC_RAW isn't interrupted by ntp but MONOTONIC IS so it's big diff.

zeljko

Well, As long as it is documented properly, I don't think there is anything wrong with such an implementation.

Michael.

With that argumentation you could question any usage of syscalls in FPC as we're not using syscalls on Mac OS X...

Or maybe, the question should be the opposite, why not? Why shouldn't such peripheral calls NOT be taken from libc?

If that function is indeed used to implement a fpGetTickCount which is located in one of the core units (e.g. SysUtils) I wouldn't want to link to a libc version (this is of course only if that hypothetic function gets implemented in a core unit).

Also I personally(!) prefer direct "linkage" to the kernel.

Regards,
Sven

Yes, Henry wrote that already as well...

Regards,
Sven

Except that it rules out writing standardscompliant internet applications? If the network stack isn't in userland, there
is no point in putting NowUTC or whatever in userland. Bout where are the network stacks in these legacy OS's?

Marco van de Voort wrote

IMHO that should have been done in the first place. First research and find a workable, portable way, and only then put it up for inclusion.

Well, I was expecting a lot more of discussions about how to do it, maybe even some patches over my patch to help advance to a good final result. I certainly wasn't expecting so much discussion about if we should do about NowUTC, it seams that it doesn't require any file checking at all, my error was something else, using EpochToLocal which adds the Timezone information. This can be easily corrected by adding a EpochToUTC routine and this solution works fine in this machine too ;)

In our previous episode, Michael Van Canneyt said:

Then also add the getres. Without it is useless, or will lead to bad code that makes assumptions about granularity.

It is a linux kernel call, and therefor earns its place at least in the linux unit, it is the purpose of that unit.

The linux unit is much more lowprio. The problem is more the reason.

I'll summarize it:

- I don't like getting requests for addition of new functions to central highly portable units that are so whoefully underresearched.
- This comes from an urgent need for a windows call.
- Implementation of non unix was pretty much nonexistant.
- it had the danger of dragging in stuff like timezone parsing and other possibly distribution and OS specific config files.
- Then there is a suggestion to wave it away with clock_gettime
- which doesn't exist one some systems.
- with the intended parameter (MONOTONIC_RAW) that is not portable (did sb check non x86(_64) linux?), and essentially a kernel internal's loophole.

And most important of all, I still don't see why this should be in the core RTL. Syscall, libc or whatever. It is just an liability.

And as far as libc goes, I'm talking about library libc here, not unit libc. Nobody wants unit libc back, least of all me, since I siderailled it.

But that doesn't meant that libc should be ruled out for all purposes, and then specially the ones with systemwide userland state like timezones etc.

That's a question, not an answer. We have a linux unit, for instance.

Or maybe, the question should be the opposite, why not? Why shouldn't such peripheral calls NOT be taken from libc?

Because you don't have to link to libc when you have a syscall?

Henry

In our previous episode, Sven Barth said:

True, but they are libc functions on OS X. This isn't.

I don't see why it should be in sysutils.

Also I personally(!) prefer direct "linkage" to the kernel.

Not always. See e.g. the readdir situation. Limiting the number of syscalls drastically speeds up the process.

In Windows you also often call user32, not kernel32.

In our previous episode, Thaddy said:

No, it just says that one should try to multiplex multiple intentions (timing, running some event x times per second and "standardscompliant internet applications") on the same call

In our previous episode, Henry Vermaak said:

> Or maybe, the question should be the opposite, why not? Why shouldn't such > peripheral calls NOT be taken from libc? Because you don't have to link to libc when you have a syscall?

True. You just have to maintain the syscall. And polish away the cross platform issues. For core functionality that is worth the trouble (since it is also quickly noticed when it fails), for this IMHO not.

user32 is the interface to the kernel mode driver win32k which does all the hard work regarding the user interface. So it's a basic system component like kernel32 is. You can only compare them together to an "OS interface library" like libc.

Regards,
Sven

right words like "unicode string", "iterators" etc. and you can be sure that you need to buy more popcorn :P

Regards,
Sven

That was the intention. Simply adding definitions for

int clock_getres(clockid_t clk_id, struct timespec *res);
int clock_gettime(clockid_t clk_id, struct timespec *tp);
int clock_settime(clockid_t clk_id, const struct timespec *tp);

to the linux unit, as per the linux man page for these calls. No more, no less.

Michael.

Careful, you may start a discussion about popcorn...

Michael.

Done. Revision 19789.

Michael.

Oh right O.o

I should have paid more attention ^^

Regards,
Sven

In our previous episode, Michael Van Canneyt said:

Not if it is portable...

*rofl*

That statement just made my day :D

Regards,
Sven

never say never... my OS/2 systems do know about and use the TZ environment variable... some programs on those systems also use the TZUTC environment variable... my oldest OS/2 system is Warp 3 Connect and it has been using these EVs since Warp 3 Connect was made available to the public ;)

now, i should point out, which i kinda of lightly did above, that the OS may or may not use these but those programs which know about them can and do...

I don't say never, just that neither DOS nor OS/2 enforce or validate this setting and thus it's purely up to the user to make sure that it eventually works. Not even mentioning the attempts of an author of certain command shell who apparently tries to make the situation even more confusing (however smart he may be) by trying to convince others that IBM wanted something else than what they really did :/ (if you don't know whom or what I talk about, forget it, it isn't very important).

Tomas

i understand and yes, you are right, neither of them enforces or validates this setting... i was, actually, aiming at "never" in "[...] will never be able to [...]" all my systems, OS/2, DOS, Winwhatever, and linux are set to local time... when they need to provide a UTC timestamp, they do otherwise it is local time... at least this is my experience and has been for "ever"... i have never run any of my systems in UTC time and expected them to convert all the time to local time...

however, back to the TZ and such... i wrote a library for TP6/BP6 that emulated parts of the C time stuff using a slightly modified tm_rec... i needed this so i could work on an external means of changing some settings when daylight saving switched on and off in my area... these settings were specific to a few programs and i wanted to automate the switchover so that their outputs were not an hour off either way... i even took the opportunity to "borrow" novell's DSTSTART and DSTSTOP style settings... they look like this...

DSTSTART=second sunday in march at 2:00
DSTSTOP=first sunday in november at 2:00

granted, that info may be gleaned from the long form of TZ but i didn't code for that in my stuff at that time... i was only interested in the current timezone, what the offset from UTC was at the time, and when daylight saving switched on and off... i still use this at least eight year old code in numerous projects i still maintain with TP/BP6 ;)

yes, i know exactly who you are talking about ;) i was an active beta tester of his products as well as a distributor of them on fidonet... i'm still on fidonet but haven't heard anything from JdBP in a long while...