Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Unix clone in about a month

drewdevault.com

Post reply on HN
Print view View original

61–70 of 140 posts

Re: Writing a Unix clone in about a month

#61

Post by convolvatron »

chasil wrote: post #50
kpw94 wrote: post #18

> I also finally learned how signals work from top to bottom, and boy is it ugly. I’ve always felt that this was one of the weakest points in the design of Unix and this project did nothing to disabuse me of that notion. Would love any resources that goes in more details, if any HN-er or the author himself knows of some!

There were differences between BSD and SYSV signal handling that were problematic in writing portable applications. https://pubs.opengroup.org/onlinepubs/009604499/functions/bs... It's important to remember that code in a signal handler must be re-enterant. "Nonreentrant functions are generally unsafe to call from a signal handler." https://man7.org/linux/man-pages/man7/signal-safety.7.html

reentrancy is not sufficient here - at least that provided by mutex style exclusion. the interrupted thread may have actually been the one holding the lock, so if the signal handler enters a queue to wait for it, it may be waiting quite a while

Re: Writing a Unix clone in about a month

#62

Post by beryilma »

andsoitis wrote: post #2

Impressive, super cool, and inspiring! Example of “creating something impressive in X days” requires a lot of experience and talent that is built over years .

Versus now... I changed the text on a button with an internationalized string. It only took me about a week.

I put the English string in the catalog, updated a number of tests, run the tests on the local system, pushed the change to staging cluster, fix unanticipated test failures, push the change to production, contact the translators to have the string translated to a number of languages, and have documentation updated.

Re: Writing a Unix clone in about a month

#63

Post by balder1991 »

chubot wrote: post #45
kpw94 wrote: post #18

> I also finally learned how signals work from top to bottom, and boy is it ugly. I’ve always felt that this was one of the weakest points in the design of Unix and this project did nothing to disabuse me of that notion. Would love any resources that goes in more details, if any HN-er or the author himself knows of some!

If you haven't already, I would start with Advanced Programming in the Unix Environment by Stevens https://www.amazon.com/Advanced-Programming-UNIX-Environment... It is about using all Unix APIs from user space, including signals and processes. (I am not sure what to recommend if you want to implement signals in the kernel, maybe https://pdos.csail.mit.edu/6.828/2012/xv6.html ) --- It's honestly a breath of fresh air…

I believe this was the 3rd time I’ve seen this book being recommended this week. It must mean something.

Re: Writing a Unix clone in about a month

#64

Post by Terr_ »

balder1991 wrote: post #63
chubot wrote: post #45

Earlier quoted context omitted.

If you haven't already, I would start with Advanced Programming in the Unix Environment by Stevens https://www.amazon.com/Advanced-Programming-UNIX-Environment... It is about using all Unix APIs from user space, including signals and processes. (I am not sure what to recommend if you want to implement signals in the kernel, maybe https://pdos.csail.mit.edu/6.828/2012/xv6.html ) --- It's honestly a breath of fresh air…

I believe this was the 3rd time I’ve seen this book being recommended this week. It must mean something.

It might mean the Baader–Meinhof effect.

Re: Writing a Unix clone in about a month

#65

Post by madhadron »

balder1991 wrote: post #63
chubot wrote: post #45

Earlier quoted context omitted.

If you haven't already, I would start with Advanced Programming in the Unix Environment by Stevens https://www.amazon.com/Advanced-Programming-UNIX-Environment... It is about using all Unix APIs from user space, including signals and processes. (I am not sure what to recommend if you want to implement signals in the kernel, maybe https://pdos.csail.mit.edu/6.828/2012/xv6.html ) --- It's honestly a breath of fresh air…

I believe this was the 3rd time I’ve seen this book being recommended this week. It must mean something.

It's been the standard reference for decades for a reason. I learned from it, too. There's really nothing else quite like it available.

Re: Writing a Unix clone in about a month

#66

Post by Muromec »

beryilma wrote: post #62
andsoitis wrote: post #2

Impressive, super cool, and inspiring! Example of “creating something impressive in X days” requires a lot of experience and talent that is built over years .

Versus now... I changed the text on a button with an internationalized string. It only took me about a week. I put the English string in the catalog, updated a number of tests, run the tests on the local system, pushed the change to staging cluster, fix unanticipated test failures, push the change to production, contact the translators to have the string translated to a number of languages, and have documentation upd…

So... It goes to production before you get translations to all the languages?

Re: Writing a Unix clone in about a month

#67

Post by pjmlp »

balder1991 wrote: post #63
chubot wrote: post #45

Earlier quoted context omitted.

If you haven't already, I would start with Advanced Programming in the Unix Environment by Stevens https://www.amazon.com/Advanced-Programming-UNIX-Environment... It is about using all Unix APIs from user space, including signals and processes. (I am not sure what to recommend if you want to implement signals in the kernel, maybe https://pdos.csail.mit.edu/6.828/2012/xv6.html ) --- It's honestly a breath of fresh air…

I believe this was the 3rd time I’ve seen this book being recommended this week. It must mean something.

It is a must for anyone serious about UNIX programming.

Additionally one should get the TCP/IP and UNIX streams books from the same collection.

Re: Writing a Unix clone in about a month

#68

Post by pjmlp »

senkora wrote: post #22
nickcw wrote: post #10

Hare looks like an interesting language. Though this limitation will limit its adoption in this multicore age I think: From the FAQ https://harelang.org/documentation/faq.html .... Can I use multithreading in Hare? Probably not. We prefer to encourage the use of event loops (see unix::poll or hare-ev) for multiplexing I/O operations, or multiprocessing with shared memory if you need to use CPU resources in parallel.…

> multiprocessing with shared memory if you need to use CPU resources in parallel This is actually pretty powerful. I personally prefer it for most purposes, because it restricts the possibility of data races to only the shared memory regions. It's a little like an "unsafe block" of memory with respect to data races.

I changed from a strong threads believer and dynamic libraries plugins, exactly because of attack vector and host program stability.

Re: Writing a Unix clone in about a month

#69

Post by 2pEXgD0fZ5cF »

samatman wrote: post #7

I was interested in Hare until I found this immensely self-defeating FAQ item: https://harelang.org/documentation/faq.html#will-hare-suppor... As a baseline, I support developers using whatever license they would like, and targeting whatever operating systems, indeed, writing whatever code they would like in the process. That doesn't make this specific policy a good idea. Even FSF, generally considered the most extre…

> Languages either snowball or fizzle out.

This is not true and a naive statement. There are quite few languages which are not popular across the board but have a very firm niche in which they thrive and fulfill critical roles.

Re: Writing a Unix clone in about a month

#70

Post by tedunangst »

convolvatron wrote: post #61
chasil wrote: post #50

Earlier quoted context omitted.

There were differences between BSD and SYSV signal handling that were problematic in writing portable applications. https://pubs.opengroup.org/onlinepubs/009604499/functions/bs... It's important to remember that code in a signal handler must be re-enterant. "Nonreentrant functions are generally unsafe to call from a signal handler." https://man7.org/linux/man-pages/man7/signal-safety.7.html

reentrancy is not sufficient here - at least that provided by mutex style exclusion. the interrupted thread may have actually been the one holding the lock, so if the signal handler enters a queue to wait for it, it may be waiting quite a while

That's why the word reentrant is used, not thread safe.
Post reply on HN