C When pthreads will work properly on FreeBSD?

lol, funny, but a reboot fixed it
after googling a bit, it turns out that this bug exists for 7 years at least https://forums.freebsd.org/threads/signature-is-not-valid-pkg.47200/
Looks like it was fixed in 2018.
https://github.com/freebsd/pkg/issues/1676

/me grabs large bag of popcorn... :)

Heh. If you disable binary space partitioning and occlusion culling, it could make a fun test. Generally you would also start needing a fairly hefty multi-core CPU just to copy the sheer number of pixels to a HD resolution framebuffer.
 
hmm okay, i accept that explanation, as my internet connection is really dying since the apperance of corona chan
 
Generally you would also start needing a fairly hefty multi-core CPU just to copy the sheer number of pixels to a HD resolution framebuffer.

Yes. Thats why i need pthreads to work properly for this project.
 
Yes. Thats why i need pthreads to work properly for this project.
We already clarified FreeBSD 6 introduced a pthreads implementation that could map all threads to kernel-level threads. That was released 2005. You *could* do it wrong as a programmer back then by chosing libpthread and NOT explicitly requesting the system contention scope (which already was the default when instead using libthr).

In comparison, Linux 2.6 was released in december 2003 and was the first release to include nptl, which was Linux' implementation of POSIX threads using kernel-level threads.

So, whatever you did, you did it wrong OR tried earlier than 2005.

And just as a side note, an implementation only offering user-level threads is perfectly POSIX compliant. It's just not that useful in times when every CPU has multiple cores.
 
i mean thats why i have opened the topic, because i cant do a bsd release without threads utilizing the cores, the users would smug at me.
 
Well, you imply FreeBSD would use user-level threads in the title already (which hasn't been the case for >15 years, in terms of computer technology, this is ancient history), and you shout out it's a BUG (which it wouldn't be, even if it WAS the case).

Sounds much more like trolling to me.
 
aaaaAAAAAAND ba dumm tss it works
because i get cpu utilization above 200% in top which means at least two from the 4 cores are utilized by my process

Ov7ED3G.png

indeed it was a bug in bsd, because the old bsd, because i havent modified anything in the threading code for a decade or so
the patch had to came to bsd in the recent years.
 
I think it could be that qemu (or qemu-kvm, you still haven't told us the VM platform you are using) now supports emulating multiple cores.

qemu is unfortunately very Linux centric. It can't even get MS-DOS quite right.
 
Zirias, the documents proving that this issue was in freebsd itself, were actually linked by you, but this issue does not matters any more, as right now it works as its intended to be.

And now, as a present for tolerating my ego for this long,

i have upgraded Maker4D runtime packages with a 64 bit FreeBSD binary.


So now you can put an X for having a real game engine ported for your operating system.

This is a beta version, and it could have issues with:
1. hotkeys
2. sound
3. joystick

It should not have issues with stability. This is a quick port, so a normal port will arrive later on.
 
I must admit, this doesn't quite match a TempleOS level of dedication, but the 3d-fication algorithm is a work of art. Bad art, that is.

GOD says one CPU core is enough.
-All FreeBSD developers, 198x-2005
R.I.P.
 
malavon you can now stop. The FreeBSD community no longer requires your work on UE4.

unreal, cry engine, irrlicht, ogre3d, and other hyped WASD modelviewer engines are also very important, because after the users realize how useless those are, its easyer to sell them game makers.
 
I did chuckle a little. But I also know that is a fairly difficult problem to solve. So I reserve judgement ;)

It sure looks unique.

big cuts had to be made on the animation system and the 3d gen algorithm.

i dont want it to do calculations for multiple seconds, when a new hero or npc has to be loaded as users walking from map to map, that would be imho worse experience than having glitches in the models.

this algorithm will be fine tuned further - the original one was far terrible than this :D
 
Last time when I have tested FreeBSD a few years ago, threads created with pthread was still not able to utilize multiple CPU cores. This made me to permanently halt all software development for BSD.

Currently however I plan to restart some development for FreeBSD, and release binaries for BSD from my new game engine (which uses software rendering, therefore threads are required to have a good experience on modern computers).

When can I expect this 25 year old BUG to be fixed (no, it's not a feature, no, it's not normal behavior, despite what you read in 30 year old handbooks, we live in 2021).
Wow, shocking news to me. I'm going to have to reappraise my reality because it obviously differs from actuality!

Ignoring all your self aggrandisement, the fact you are NOW, after making this vastly wrong statement, installing FreeBSD to test your wacky theories stands as a beacon to how a troll works.

I nominate this as troll post of the year. Yes, it's early days, but, I'm willing to bet big on this doozy!

Mike drop. :eek:
 
if you think my goal with this topic was harsh provocation, you are misunderstanding my intentions.
anyway i got the info i wanted on pthreads, even a quick release turned out to be fine, so good night
 
theory? it was even written in the pthread whitepaper zirias already linked.
I am sure you're a troll.
If you want to seriously determine the suitability of FreeBSD you would have installed FreeBSD, compiled your masterpiece and then, IF IT FAILED, come in here and complain. Instead you complain about what was the case 30 years ago?

This topic is as idiotic as me posting on Apple's forums about MacOS8 never having pre-emptive multi-tasking and berate them for it.

Subject: "When will MacOS support pre-emptive multi-tasking".

Content:
Last time when I have tested MacOS a few years ago, pre-emptive multi-tasking didn't work. This made me to permanently halt all software development for MacOS.

Currently however I plan to restart some development for MacOS, and release binaries for MacOS from my new game engine (which uses software rendering, therefore pre-emptive multitasking are required to have a good experience on modern computers).

When can I expect this 25 year old BUG to be fixed (no, it's not a feature, no, it's not normal behavior, despite what you read in 30 year old handbooks, we live in 2021).

Troll.
 
i have never asked anyone to agree with me, i explained why i am not going to use it. you write code whatever you want to write in, and what i write code in is not something you can vote about
Once again, I'm sad that this forum only allows two reaction emojis, "thanks" and "thumbs up", and it allows only one emoji per post. This post requires two, neither of which is available: laughter and anger.
 
Back
Top