Search logs: #osdev2 - 17 January 2023

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=1&d=17

Tuesday, 17 January 2023

01:35:00 <zid> why does my right headphone no longer the noise
01:36:00 <kaichiuchi> i ate it
01:38:00 <zid> ah fun, ground is snapped
01:50:00 <zid> yay, stero again
01:51:00 <zid> thankfully it had broken at the solder joint, splicing headphone wire is damn impossible
01:51:00 <zid> so just had to touch it back to the pad with an iron and done
02:02:00 <gog> i've had to do that a couple times
02:05:00 <zid> these headphones are so fucked
02:05:00 <zid> the left cup is taped on, right phone had no stereo, etc
02:22:00 <epony> ^ matches the CPU support in software, it's like that too
03:02:00 <zid> gog: got 100 hours into space exploration now?
04:37:00 can any form of sigwait* cause a signal to be removed from the queue
10:52:00 <heat> small, yes
10:53:00 <heat> i.e "sigwaitinfo() removes the signal from the set of pending signals and returns the signal number as its function result."
11:07:00 <heat> also re: your question in #musl, signal handling has little to do with the libc, traditionally
11:07:00 <heat> it's usually all done in the kernel
11:36:00 hmm
11:36:00 [15:29] <cryptonector> sigwait() does not remove the signal from the pending set
11:36:00 from #posix
11:37:00 from ##posix *
11:38:00 heat:
11:51:00 <heat> small, they're wrong
11:54:00 <heat> small, also https://pubs.opengroup.org/onlinepubs/9699919799/ "The sigwait() function shall select a pending signal from set, atomically clear it from the system's set of pending signals, and return that signal number in the location referenced by sig."
11:54:00 <bslsk05> pubs.opengroup.org: The Open Group Base Specifications Issue 7, 2018 edition
11:54:00 <heat> ironic that someone in ##posix says such blatantly wrong things without looking at posix itself lol
12:15:00 o.o
12:16:00 <QuietlyConfident> heat: sometimes people do dumb stuff
12:16:00 <QuietlyConfident> or say dumb stuff
12:22:00 do all functions that wait for a signal also remove that signal from the set of pending signals
12:24:00 <sham1> I'd hope so, otherwise there really wouldn't be a reason to wait for them, now would there
12:27:00 <heat> no
12:27:00 <heat> pause() doesn't
12:28:00 <heat> neither does sigsuspend
12:28:00 <heat> the only ones that do are the ones that extract useful information out of it (siginto_t *, int signum, whatever)
12:33:00 alright
12:34:00 <heat> and to be clear, removing a signal from the pending set also means that the signal handler never gets called
12:34:00 hmm alright
12:35:00 would sigwaitinfo with NULL or {0,0} remove from pending set?
12:35:00 <heat> yes
12:37:00 alright, so even when "a poll is performed: sigtimedwait returns immediately, ..." the signal is removed from the pending set if it exists?
12:38:00 <heat> yes
12:38:00 <heat> can you not read?
12:38:00 yes
12:39:00 but poll usually means "see if there is data available but do not remove data" right?
12:43:00 <heat> no?
12:43:00 ok
12:43:00 <heat> please, I encourage you to read the man page or POSIX spec
12:43:00 <heat> it's all there.
12:44:00 i am
12:50:00 so, if we are inside a function that waits for a signal
12:50:00 if signal is pending and blocked, then it remains pending
12:50:00 if a signal is pending and unblocked, it will be removed from the pending set and no action is taken on that signal
12:51:00 right?
12:52:00 if so, i assume the same for a signal that becomes pending, right?
12:54:00 <heat> no
12:54:00 <heat> "During the time between the generation of a signal and its delivery or acceptance, the signal is said to be "pending"."
12:54:00 <heat> per tfm
12:58:00 so what does it do differently?
12:59:00 <heat> a signal that was kill'd or raise'd or whatever and is blocked is pending
12:59:00 <heat> if your signal unqueuing function explicitly removes from the pending set, well, ...
13:01:00 so the signal is removed regardless of wether it is blocked or not? and in both cases, if removed, no action is taken on said signal?
13:01:00 <heat> yes. again, rtfm
13:01:00 <heat> it's very explicit
13:02:00 doesnt seem like it
13:02:00 "If the action associated with a blocked signal is anything other than to ignore the signal, and if that signal is generated for the thread, the signal shall remain pending until it is unblocked"
13:03:00 and this
13:03:00 "it is accepted when it is selected and returned by a call to the sigwait() function, or the action associated with it is set to ignore the signal."
13:04:00 doesnt specify if it applies to blocked or unblocked signals
13:04:00 or both
13:05:00 <heat> how does it not?
13:05:00 <heat> "signal shall remain pending until it is unblocked, it is accepted when it is selected and returned by a call to the sigwait() function, or the action associated with it is set to ignore the signal. "
13:07:00 <heat> 1) it gets delivered if unblocked 2) it gets accepted if select by sigwait or if the disposition is set to IGN
13:08:00 alright
13:09:00 <zid> /ignore -h heat
13:09:00 <zid> mis
13:10:00 <heat> what
13:16:00 a signal that is blocked WILL NOT invoke a signal handler nor take action unless that signal is then unblocked, right?
13:17:00 assuming said signal has not been accepted yet
13:20:00 eg, if we send a BLOCKED signal, said signal is accepted, and then said signal is UNBLOCKED, no action is taken on said signal nor is a signal handler invoked for said signal, right?
13:25:00 eg, if a signal becomes UBLOCKED, then action and signal-handlers are taken/invoked ONLY if said signal is STILL in the pending signals, right?
13:26:00 (in which case, if such unblocked signal goes into pending then action/signal-handlers are taken/invoked as soon as possible as long as no threads are currently waiting for such signal, right?
13:50:00 heat:
13:55:00 <gog> hi
13:56:00 <zid> gog: got 100 hours into space exploration now?
14:04:00 <gog> no
14:04:00 <gog> i can run a mile in 6m45s
14:04:00 <zid> I can run a mile.
14:05:00 <gog> in how long?
14:05:00 <Ermine> gog: may I pet you
14:05:00 <zid> gog: You promsied you'd do better as a person, I am upset
14:05:00 <gog> Ermine: yes
14:05:00 <zid> Oh we have to time it, idk, a week?
14:05:00 <gog> lol
14:05:00 * Ermine pets gog
14:14:00 * gog prrr
14:19:00 <clever> 1;2A
14:20:00 <clever> oops
15:04:00 <sham1> Stop haxxing my terminal
15:10:00 <zid> sham1: ESC[3J
15:10:00 <zid> you ain't seen nothing, roiht?
15:11:00 <sham1> Damn it, blanking my screens like a bozo
15:27:00 <kaichiuchi> hi
15:30:00 <heat> gog, did u like my pussy
15:32:00 <kaichiuchi> heat: ba
15:32:00 <heat> zinga
15:34:00 <kaichiuchi> windows is updating at work
15:34:00 <kaichiuchi> and i am sitting here bored
15:35:00 <kaichiuchi> it will probably take forever to update
15:42:00 <gog> heat: bussy
16:02:00 <kaichiuchi> I think I might have a stroke
16:02:00 <kaichiuchi> my fix for this bug might’ve not actually worked
16:03:00 <heat> gog, i have not sent you that, yet
16:04:00 <heat> be nice or you'll get that in your inbox
16:07:00 <gog> i'm doing inadvisable thigns in javascript
16:10:00 <QuietlyConfident> javascript was a mistake
16:10:00 <QuietlyConfident> doing anything with it is inadvisable
16:11:00 <clever> gog: ive used javascript to load ram-init code into an SoC before
16:18:00 <gog> nice
16:20:00 <clever> the bcm2835 on the pizero, can load the ram-init stage over a usb-device protocol
16:20:00 <clever> and javascript has webusb
16:21:00 <clever> just port over the existing program, and done!
16:22:00 <gog> aaay i got the thing i was doing to work
16:40:00 <ddevault> gz
17:19:00 <kaichiuchi> gog: i want to hear a story
18:30:00 <kaichiuchi> hm…
18:30:00 <kaichiuchi> very interesting
18:31:00 <kaichiuchi> the register keyword does have an effect with optimizations disabled
18:31:00 <kaichiuchi> i didn’t think it would have any effect at all
18:31:00 <Ermine> why do you use that
18:31:00 <kaichiuchi> i don’t
18:31:00 <kaichiuchi> i was curious
18:32:00 <kaichiuchi> but game programmers might care
18:32:00 <Ermine> Now that your curiosity is fulfilled, don't use that keyword
18:34:00 <kaichiuchi> https://godbolt.org/z/ejcGGde5o
18:34:00 <bslsk05> godbolt.org: Compiler Explorer
18:35:00 <gog> it's better to let the compiler decide
18:36:00 <kaichiuchi> yes yes i know
18:36:00 <kaichiuchi> but game programmers have to care about debug performance
18:36:00 <sham1> Even then it's better to let the compiler decide. register is bollocks
18:36:00 <kaichiuchi> something I must stress: I DO NOT USE THIS KEYWORD
18:37:00 <gog> good, don't
18:37:00 <kaichiuchi> well take a look at the disassembly and tell me if i’m seeing things
18:37:00 <sham1> kaichiuchi: and neither should games protrammers
18:37:00 <kaichiuchi> they have to do a lot of things that most would consider whack
18:37:00 <kaichiuchi> y
18:38:00 <gog> change the lower one to -O1
18:38:00 <kaichiuchi> yes that’s all well and good
18:39:00 <gog> it inlines the static
18:40:00 <kaichiuchi> man can’t you just let me play :(
18:40:00 <gog> ok fine
18:40:00 <gog> :P
18:40:00 <sham1> No
18:40:00 <kaichiuchi> all I’m saying is
18:40:00 <kaichiuchi> game programmers have bitched about debug performance, -O0
18:40:00 <kaichiuchi> they go to enormous lengths
18:41:00 <lockna> Isn't the register keyword more like a hint to the compiler but he could well on ignore it?
18:41:00 <kaichiuchi> register *is* having an effect, is all i’m saying, at -O0
18:41:00 <kaichiuchi> lockna: it’s pretty much ignored when optimizations are enabled
18:41:00 <lockna> ah, yeah
18:41:00 <lockna> thanks
18:42:00 <kaichiuchi> but when optimizations are disabled, the compiler has to play dumb
18:42:00 <gog> does the compiler error if you try to take the address of a variable delcared register
18:42:00 <kaichiuchi> yes
18:42:00 <gog> ok
18:44:00 <kaichiuchi> there’s an interesting advantage
18:44:00 <kaichiuchi> the compiler knows ‘x’ won’t be aliased
18:45:00 <sham1> You also can't take the address
18:46:00 <gog> yes ofc you can't take the address of a register
18:46:00 <kaichiuchi> yea
18:46:00 <kaichiuchi> yes*
18:46:00 <gog> but what if
18:46:00 <gog> it returned the register :o
18:46:00 <gog> i know it can't
18:46:00 <gog> i'm joking
18:46:00 <gog> nvm
18:46:00 <kaichiuchi> some older compilers might need register to do anything useful
18:47:00 <kaichiuchi> and by old I mean when I was still learning my a b c’s
18:47:00 <gog> those compilers need to be regired
18:47:00 <gog> retired
18:49:00 <sham1> They need to be puts on sunglasses registered
18:49:00 <kaichiuchi> some old compilers are used in certain fields sadly
18:50:00 <ddevault> https://a.uguu.se/cVygHtuX.jpg
18:51:00 <zid> gog: register rax asm("rax"); &reg should be a pointer to the string "rax"
18:51:00 <zid> clearly
18:51:00 <gog> yes'
18:51:00 <gog> exactly
18:51:00 <ddevault> https://git.sr.ht/~sircmpwn/helios-talk/tree/master/item/cmd/slidedeck/main.ha
18:51:00 <bslsk05> git.sr.ht: ~sircmpwn/helios-talk: cmd/slidedeck/main.ha - sourcehut git