Linux doesn't even have proper kernel support for userspace threads wtf?

linux doesn't even have proper kernel support for userspace threads wtf?

why don't you use superior freebsd?

Other urls found in this thread:

stackoverflow.com/questions/807506/threads-vs-processes-in-linux
stackoverflow.com/questions/8244073/thread-control-block-in-linux
lxr.free-electrons.com/source/include/linux/sched.h#L1388
lxr.free-electrons.com/source/include/linux/sched.h#L1509
lxr.free-electrons.com/source/include/linux/sched.h#L1523
stackoverflow.com/questions/9305992/linux-threads-and-process
lmgtfy.com/?q=Is Linux a microkernel
en.wikipedia.org/wiki/Monolithic_kernel#Loadable_modules
informit.com/articles/article.aspx?p=370047&seqNum=3
twitter.com/SFWRedditVideos

BSD doesn't respect your freedoms as it isn't GPL

Because I use the superior OpenBSD

Good thing I'm not a mentally ill freetard.

Sell me on BSD

...

This hasn't convinced me of anything

...

>2016
>Posting a graph from 2008

linux is literally crap

>Still posting pictures from 2008

>2008+8
>linux support for zfs is still shit

How has bsd improved recently?
By recently, I mean since the last time I fell for the bsd meme.

>linux doesn't even have proper kernel support for userspace threads wtf?
Uh, what the fuck are you talking about?

>hurr durr Linux sucks because it doesn't have ZFS
>completely disregarding the fact that it has a non-GPL compliant license preventing it from being included in the kernel

>superior BSD
>we can't into SMP yet
top fucking kekeroni!

>support for zfs
no biggie, zfs is shit anyway

What applications are available for FreeBSD?

Oh you know, user space threads, for when the architecture requires low level virtualization to multi-thread your driver cores and the remaining cache is less than 512 KB. You need to shift the process levels to a different logic tables or your thread is going to cycle, possibly causing memory leaks.

>fox and the grapes

Could you guys PLEASE stop using so many acronyms? I'm on my phone and googling every other word in your posts is a pain in the ass.

>Oh you know, user space threads
Yes. Linux have these.

>or when the architecture requires low level virtualization to multi-thread your driver cores and the remaining cache is less than 512 KB
>You need to shift the process levels to a different logic tables or your thread is going to cycle, possibly causing memory leaks.
Now you're just putting in some random words you don't really understand what means in order to sound smart.

>Now you're just putting in some random words you don't really understand what means in order to sound smart.
It's like you have that neurological disorder that makes music sound like noise to you, but instead of music, it's humor.

Hey summerfag, try not being a dumbass

>user space threads
>kernel support
u wot m8?

Because I use the superior BSD: OSX/Darwin

>phone
reddit is that way

get raped and die, mobile trash

I have a PC, it's just at home.

Why doesnt Torvald just reverse engineer an intercompatible ext file system then? It's basically just 128 bit ext

...

Linux doesn't really have user space threads

It has processes that share their address space or whatever (you use the clone() syscall and give it options such as share open files, share heap segment etc., fork() is just clone() with a specific set of options), but from the kernel's perspective, there is no difference between these "threads" and full processes

>the grapes have terrible fragmentation
>you need to keep at least 20% free space or the grapes turn to shit performance

>doesn't really
it doesn't really have support for html either

GPL has no bearing about ZFS being in Linux. If they wanted ZFS in Linux, they will write an implementation of it.

>Linux doesn't really have user space threads
Well obviously since Linux is a kernel.
Plenty of user space libraries with user space threads though.

Completely different

You can't create a thread in Linux, but you can create a new process that shares things like address space with its parent

Meant kernel support for threads that are created from userspace

What kernel support for threads do you need? What does it even do that's better than userspace threads?

>Linux doesn't really have user space threads
It really does.

> there is no difference between these "threads" and full processes
That's a lie. Look up the difference between Process Control Block and Thread Control Block in Linux.

Processes (fork()) cannot share heap, they have their own virtual address space. You need to use shared memory in order to do so. Threads, on the other hand, are part of the process.

You know they can't just take the code and relicense it right? You know that that's a copyright violation?

>You can't create a thread in Linux, but you can create a new process that shares things like address space with its parent
See Threads are not processes.

So don't take the code and relicense it. Write a new implementation using official ZFS as a guide. Problem solved.

>You know they can't just take the code and relicense it right? You know that that's a copyright violation?

both of the anons you quoted said something to the effect of

"write their own implementation and release it"
not "copy-paste the source code and release it"

>no drivers
>no software
>no support
>no fucking drivers

but hey guys it uses some clown-mode file system you should totally install it

stackoverflow.com/questions/807506/threads-vs-processes-in-linux

clone() with CLONE_VM, CLONE_FILES, etc.

See
Though in practice it doesn't matter from user space

>just make this thing from scratch that took almost a hundred different engineers 20 years to perfect

>parrotting stackoverflow
The guy obviously doesn't know what he is talking about. See PCB vs TCB

Why would they be two entirely different data structures (in fact, a PCB can contain multiple TCBs) if "hurr durr threads are just lightweight processes"

This book says the same

I don't see what your point is.
'Threads' are just an abstraction (i.e individual units of execution which things like share address space and file descriptors).
So, you can create these 'threads' from user space just fine.
The fact that Linux accomplishes through just one syscall which takes different flags for how much these units of execution should share is an irrelevant implementation detail.

>google "linux thread control block"
>get this
stackoverflow.com/questions/8244073/thread-control-block-in-linux

Please link me to the source line you claim exists which begins the definition of this TCB

I don't give a fuck about what "the book" says

Here is the process control block definition

lxr.free-electrons.com/source/include/linux/sched.h#L1388

Here is where child processes are stored:

lxr.free-electrons.com/source/include/linux/sched.h#L1509

Here is where threads are stored:

lxr.free-electrons.com/source/include/linux/sched.h#L1523

See Threads and processes are treated differently.

You seem to not understand what thread groups are

stackoverflow.com/questions/9305992/linux-threads-and-process

Please show me the definiton of the TCB

Why are you sageing and reposting your shitty stackoverflow link?

It's a different link that explains thread groups

Show me the TCB

If it isn't just the same as the PCB it must be defined somewhere, right?

I told you threads and processes were treated differently, you're the one going on about PCB and TCB....

The book is written by one of the kernel maintainers

I'd rather trust him than some random guy on Sup Forums

>see PCB vs TCB

It is written by the same guy that gave the world the abomination that is NetworkManager....

That's not me, I'm and

He just worked on it, and that is irrelevant

>zfs

Enjoy extortion lawsuits from Oracle.

>"he just worked on it"
Are you fucking copy-pasting shit from wikipedia now? wow...

Well the fact that they list their threads and child processes differently doesn't mean they are treated differently by the scheduler or anything. Every new thread gets a new task_struct like any new process and it is scheduled just like it was a completely separate process.

How do you know what Wikipedia says?

Anyway I looked it up as I had no idea about his (irrelevant) involvement with it

BSD doesn't have any drivers only ported Linux drivers.

>Well the fact that they list their threads and child processes differently doesn't mean they are treated differently by the scheduler or anything
What has scheduling to do with whether or not it's a lightweight process or something completely different (thread)?

You know that even threads need to be scheduled, right?

>Every new thread gets a new task_struct like any new process
But with completely different fields and values and size (see the Linux object handling system).

>and it is scheduled just like it was a completely separate process.
See my first point. By this logic kernel threads are processes too, because they are also scheduled.

>His background is only relevant when I decide it is and irrelevant when I decide that
Okay....

The only thing which matters for a scheduler is priority and time slices, and the priority score for a task takes into account whether they are child tasks, in the same thread group or not, etc.

Meanwhile, Darwin and NT have already moved to a performant hybrid micro + monolithic kernel architecture while Linux refuses to move on past Tanenbaum-induced butthurt and is still dealing with the kernel scheduler encouraging idling, causing ~20% latency increases for regular database operations over the past decade.

Linux is a hybrid kernel (see loadable kernel modules).
XNU is a proper Mach microkernel.

Darwin isn't even the name of the kernel you stupid fuck.

Yes, but they are added to the main list of processes just like they were processes and the scheduler schedules them without knowing if they aare threads or processes, and there is no difference between "the process" and any "threads" spawned by it in how they are managed

If you look at Windows NT threads are very different

Feel free to tack on that possessive s to Darwin if it soothes your butthurt buddy. I don't mind at all.

His background related to the thing is relevant, and the rest isn't. This shouldn't be surprising.

It doesn't matter if you thought Torvalds' diving app wasn't great, his role with the Linux kernel makes him an authority on that, just like Love.

>Yes, but they are added to the main list of processes just like they were processes and the scheduler schedules them without knowing if they aare threads or processes, and there is no difference between "the process" and any "threads" spawned by it in how they are managed
But THEY ARE SCHEDULED DIFFERENTLY you stupid fuck. See Why do you think the priority score takes the thread group into account?

>If you look at Windows NT threads are very different
Nobody "looks" at Windows NT, unless they are employed by Microsoft, because it's proprietary you idiot.

XNU is a hybrid kernel

>his background related to this thing that is part of the kernel is relevant but his background related to this other thing that is also part of the kernel isn't

There's plenty of books about Windows NT

The fact that it cares about the thread group number doesn't make them fundamentally different. If I take an arbitrary process and change its group number to another's, will it suddenly be a thread of that process?

Protip: They're all hybrid kernels

>If I take an arbitrary process and change its group number to another's, will it suddenly be a thread of that process?
No, because a process isn't a thread.

...

Okay but pretty much everyone else disagrees with you.

Strange how none of Linux kernel maintainers know how threads work.

>There's plenty of books about Windows NT
So *BSD have better thread models because there are some books that say that in Windows NT threads work this or that way and that's different than Linux so obviously the BSDs have better thread models

I give up

No one said either approach is better

This is the only correct answer right here. Heil DeRaadt, praise tedu

>2.6

>Okay but pretty much everyone else disagrees with you.
Go ahead and try then. Try to make a separate process a thread of another process.

>Strange how none of Linux kernel maintainers know how threads work.
I'm never said anything remotely like this. I'm saying YOU don't understand how threads work in Linux.

It literally says so in OP

Where? Which chapter and section?

So Robert Love, a kernel maintainer, is wrong about there being no real difference between processes and threads?

Better send him an email before he gets into an embarrassing situation.

lmgtfy.com/?q=Is Linux a microkernel

en.wikipedia.org/wiki/Monolithic_kernel#Loadable_modules

No one ITT said Linux was a microkernel. It is a HYBRID kernel.

>So Robert Love, a kernel maintainer, is wrong about there being no real difference between processes and threads?
See

informit.com/articles/article.aspx?p=370047&seqNum=3

Stop acting childish and please explain your claim, that you can just change the thread group of a process and suddenly it will somehow become a thread of another process.

Anyone used ghostbsd?

>You can't create a thread in Linux
You're an idiot.

>clone can't be called from userspace
m8...

I never claimed that. I asked a rhetorical question.

What is childish about believing a kernel maintainer understands the kernel better than you do?

It creates a new process that shares things like the address space with its parent

>What is childish about believing a kernel maintainer understands the kernel better than you do?
Are you Robert Love?

No. Stop talking on his behalf. I'm saying YOU don't understand Linux' thread model, and you've clearly demonstrated this over and over again ITT by saying stuff like "you can't create a thread in Linux" and "you can just change the thread group of a process and make it a thread of another process".