Re: [Firebird-devel] Signals support

[Mike N. <ta...@al...>]

Note: This post is quite OT. It has nothing to do with Firebird per se.
However, since it might contain some interesting bits for some readers, I
posted it.

Fred Polizo Jr. wrote:

> I wasn't suggesting the use of POSIX on Win32.

True, but you did comment that it was unfortunate that Win32 probably would
not implement it. Else the sad emoticon wouldn't have been added.

> Nor was I comparing POSIX to Win32. My comment was more of a
> lament that Win32 doesn't support POSIX well, and never will. :(

Obviously not, Win32 isn't even close to POSIX! :-) And again you display
your disapproval of Win32 not implementing (well, OK, "supporting") it.

That's not a bad thing in itself. Lack of diversity is what makes stuff like
MSBlaster, CodeRed, and Bills Ringworm (I believe they renamed it "slammer"
later on) viable. Should any worm ever get a root-shell where it could
get/expect realtime response, I'd rather use a non-realtime system at that
time. (I just mentioned this to display that even API diversity can be a
good thing)

>  However, I was saying that some of "realtime" functionality of POSIX
> (1003.1-2001) might be useful for FireBird on POSIX, when it is available
> on the target POSIX environment.

What I reacted to was the use of "realtime", since Firebird could never get
realtime properties. I still believe what was/is intended is just low(er)
latency.

> Correct me if I'm wrong, but from your "...silly to ever suggest RT
> properties" comment, and others above, it seems that perhaps you're
> not that familiar with the POSIX functionality to which I am referring.

That is correct. I am only (more than adequate some might say) familiar with
the term "realtime".

> [Or, POSIX threads (pthreads) for that matter.]

I've used them, nothing more. Can only claim I don't know pthreads any more
than knowing different implementations made it in reality somewhat
cumbersome to use in multi-/cross-platform projects. Maybe that has changed
by the mentioned posix standard (which I'm not familiar with).

> Given that, then I think we have a misunderstanding.

Might be. Still, "realtime" has a carved in stone meaning.

I do however thank you for a most excellent writeup of what 1003.1-2001
includes. That mail is now saved, even that it would have been enough to say
that "Even that POSIX calls it realtime, its the low-latency properties that
would matter here". I believe that's where the misunderstandings started.

I also feel like commenting on a few of the items you listed, especially
since they were listed as RT "stuff":

> Memory mapped files and shared memory (improvements over SYSV)

Can never meet RT demands. It includes non-deterministic I/O.

> Memory locking (to avoid paging, supports range locking)

I've never used POSIX at this level, but is this news in POSIX land? Not
that it really matters (for this discussion), but this has been available in
Win32 for the last decade.

> Memory protection (to read/write/exec protect mapped pages)

I was on my way to write "You have got to be kidding", but then I realized
this might actually be new. Personally I've never seen a memory-protected
system (worth the name) without these features. Perhaps it's just that it
has now (2001) become POSIX and therefore is since (to be) portable?

> Memory Synchronization (flush mapped page(s) to disk)

Again, can never meet RT demands. It includes non-deterministic I/O.
(how can stuff like this be added to a realtime "extension"?)


/Mike