invalidopcode has quit [Read error: Connection reset by peer]
invalidopcode has joined #osdev
mimmy__ has joined #osdev
mimmy__ has quit [Ping timeout: 272 seconds]
mimmy__ has joined #osdev
mimmy__ has quit [Ping timeout: 246 seconds]
danilogondolfo has joined #osdev
gog has joined #osdev
xenos1984 has joined #osdev
nyah has joined #osdev
fedorafansuper has joined #osdev
fedorafa_ has joined #osdev
fedorafansuper has quit [Ping timeout: 246 seconds]
GeDaMo has joined #osdev
heat has joined #osdev
<heat>
small, yes
<heat>
i.e "sigwaitinfo() removes the signal from the set of pending signals and returns the signal number as its function result."
fedorafa_ has quit [Ping timeout: 246 seconds]
<heat>
also re: your question in #musl, signal handling has little to do with the libc, traditionally
<heat>
it's usually all done in the kernel
fedorafan has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
lockna has joined #osdev
craigo has joined #osdev
<small>
hmm
<small>
[15:29] <cryptonector> sigwait() does not remove the signal from the pending set
<small>
from #posix
<small>
from ##posix *
<small>
heat:
craigo has quit [Quit: Leaving]
craigo has joined #osdev
gog has quit [Ping timeout: 264 seconds]
<heat>
small, they're wrong
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<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."
<bslsk05>
pubs.opengroup.org: The Open Group Base Specifications Issue 7, 2018 edition
<heat>
ironic that someone in ##posix says such blatantly wrong things without looking at posix itself lol
lockna has quit [Quit: lockna]
lockna has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
lockna has quit [Ping timeout: 246 seconds]
<small>
o.o
<QuietlyConfident>
heat: sometimes people do dumb stuff
<QuietlyConfident>
or say dumb stuff
lucartc has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
<small>
do all functions that wait for a signal also remove that signal from the set of pending signals
vdamewood has joined #osdev
k0valski18891 has quit [Quit: Ping timeout (120 seconds)]
<sham1>
I'd hope so, otherwise there really wouldn't be a reason to wait for them, now would there
<heat>
no
<heat>
pause() doesn't
<heat>
neither does sigsuspend
<heat>
the only ones that do are the ones that extract useful information out of it (siginto_t *, int signum, whatever)
<small>
alright
<heat>
and to be clear, removing a signal from the pending set also means that the signal handler never gets called
<small>
hmm alright
<small>
would sigwaitinfo with NULL or {0,0} remove from pending set?
<heat>
yes
<small>
alright, so even when "a poll is performed: sigtimedwait returns immediately, ..." the signal is removed from the pending set if it exists?
<heat>
yes
<heat>
can you not read?
<small>
yes
<small>
but poll usually means "see if there is data available but do not remove data" right?
<heat>
no?
<small>
ok
<heat>
please, I encourage you to read the man page or POSIX spec
<heat>
it's all there.
<small>
i am
<small>
so, if we are inside a function that waits for a signal
<small>
if signal is pending and blocked, then it remains pending
<small>
if a signal is pending and unblocked, it will be removed from the pending set and no action is taken on that signal
<small>
right?
<small>
if so, i assume the same for a signal that becomes pending, right?
<heat>
no
<heat>
"During the time between the generation of a signal and its delivery or acceptance, the signal is said to be "pending"."
<heat>
per tfm
<small>
so what does it do differently?
<heat>
a signal that was kill'd or raise'd or whatever and is blocked is pending
<heat>
if your signal unqueuing function explicitly removes from the pending set, well, ...
qubasa has quit [Ping timeout: 260 seconds]
<small>
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?
<heat>
yes. again, rtfm
<heat>
it's very explicit
<small>
doesnt seem like it
<small>
"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"
<small>
and this
<small>
"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."
<small>
doesnt specify if it applies to blocked or unblocked signals
<small>
or both
<heat>
how does it not?
<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. "
fedorafan has quit [Ping timeout: 256 seconds]
<heat>
1) it gets delivered if unblocked 2) it gets accepted if select by sigwait or if the disposition is set to IGN
<small>
alright
<zid>
/ignore -h heat
<zid>
mis
fedorafan has joined #osdev
<heat>
what
<small>
a signal that is blocked WILL NOT invoke a signal handler nor take action unless that signal is then unblocked, right?
<small>
assuming said signal has not been accepted yet
les has quit [Quit: Adios]
<small>
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?
nick64 has joined #osdev
<small>
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?
<small>
(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?
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
gog has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
<small>
heat:
<gog>
hi
<zid>
gog: got 100 hours into space exploration now?
mimmy__ has joined #osdev
small has quit [Quit: Konversation terminated!]
<gog>
no
<gog>
i can run a mile in 6m45s
<zid>
I can run a mile.
<gog>
in how long?
<Ermine>
gog: may I pet you
<zid>
gog: You promsied you'd do better as a person, I am upset
<gog>
Ermine: yes
<zid>
Oh we have to time it, idk, a week?
<gog>
lol
* Ermine
pets gog
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
* gog
prrr
<clever>
1;2A
<clever>
oops
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
fedorafansuper has joined #osdev
fedorafan has quit [Ping timeout: 246 seconds]
lucartc has quit [Ping timeout: 256 seconds]
srjek has joined #osdev
bauen1 has joined #osdev
diamondbond has joined #osdev
<sham1>
Stop haxxing my terminal
mimmy_ has joined #osdev
Burgundy has joined #osdev
<zid>
sham1: ESC[3J
<zid>
you ain't seen nothing, roiht?
<sham1>
Damn it, blanking my screens like a bozo
mimmy__ has quit [Ping timeout: 260 seconds]
mimmy_ has quit [Ping timeout: 246 seconds]
mimmy_ has joined #osdev
fedorafan has joined #osdev
fedorafansuper has quit [Ping timeout: 256 seconds]
<kaichiuchi>
hi
<heat>
gog, did u like my pussy
gdd has quit [Ping timeout: 248 seconds]
<kaichiuchi>
heat: ba
<heat>
zinga
<kaichiuchi>
windows is updating at work
<kaichiuchi>
and i am sitting here bored
<kaichiuchi>
it will probably take forever to update
mimmy_ has quit [Ping timeout: 256 seconds]
gabi-250 has quit [Remote host closed the connection]
<gog>
heat: bussy
mimmy_ has joined #osdev
gabi-250 has joined #osdev
micttyl has quit [Quit: leaving]
srjek has quit [Ping timeout: 256 seconds]
srjek has joined #osdev
gdd has joined #osdev
<kaichiuchi>
I think I might have a stroke
<kaichiuchi>
my fix for this bug might’ve not actually worked
<heat>
gog, i have not sent you that, yet
<heat>
be nice or you'll get that in your inbox
mimmy_ has quit [Ping timeout: 268 seconds]
<gog>
i'm doing inadvisable thigns in javascript
<QuietlyConfident>
javascript was a mistake
<QuietlyConfident>
doing anything with it is inadvisable
<clever>
gog: ive used javascript to load ram-init code into an SoC before
<gog>
nice
<clever>
the bcm2835 on the pizero, can load the ram-init stage over a usb-device protocol
<clever>
and javascript has webusb
<clever>
just port over the existing program, and done!
<gog>
aaay i got the thing i was doing to work
bauen1 has quit [Ping timeout: 246 seconds]
mimmy_ has joined #osdev
<ddevault>
gz
mimmy_ has quit [Ping timeout: 264 seconds]
diamondbond has quit [Quit: Leaving]
gog has quit [Quit: Konversation terminated!]
mimmy_ has joined #osdev
mimmy_ has quit [Ping timeout: 256 seconds]
<kaichiuchi>
gog: i want to hear a story
xenos1984 has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
bauen1 has joined #osdev
gog has joined #osdev
k0valski18891 has joined #osdev
xenos1984 has quit [Ping timeout: 256 seconds]
wootehfoot has joined #osdev
wootehfoot has quit [Max SendQ exceeded]
wootehfoot has joined #osdev
xenos1984 has joined #osdev
lockna has joined #osdev
mimmy_ has joined #osdev
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
<kaichiuchi>
hm…
<kaichiuchi>
very interesting
<kaichiuchi>
the register keyword does have an effect with optimizations disabled
<kaichiuchi>
i didn’t think it would have any effect at all
<Ermine>
why do you use that
<kaichiuchi>
i don’t
<kaichiuchi>
i was curious
<kaichiuchi>
but game programmers might care
<Ermine>
Now that your curiosity is fulfilled, don't use that keyword