logs archiveBotHelp.net / Freenode / #2f30 / 2015 / August / 14 / 3
FRIGN
MakePacketLossInitializer.setRatio(80)
stateless
hahaha
you can also have your dog chew on the cable
FRIGN
MakePacketLossInitializer.getRatio().toString
stateless
hahaha
FRIGN
OO is so retarded
stateless
FRIGN, another reason tftp suits us is because the 't' stands for trivial :P
haha
FRIGN
yeeaj
^^
yeah
dami0
morning
FRIGN
hey dami0
stateless
morning dami0
dami0
stateless: what about the tinfoil side of you guys?
tftp doesn't have muh encryptions
Evil_Bob
FRIGN: http://git.codemadness.nl/sfeed/tree/ xml.c and xml.h it is ugly as balls and will need some more cleanup though
FRIGN
dami0: I encrypted your mom and she screamed her passphrase all night long.
Evil_Bob
see README.xml too
dami0
lwl
lel*
FRIGN
Evil_Bob: m4d sp33d br0
stateless: do you believe in Golden Dawn?
stateless
lol
FRIGN
yo guys, making an announcement:
Will be gone 'til Sunday evening
after that, I'll be busy from Mo-Fr
So we won't see us in a while
Evil_Bob
aw
assassination mission?
brb
stateless
FRIGN, yo check the repo
atmc
1,2 1,2 repo check
stateless
FRIGN, time to post to the bbs!!!
:P
Evil_Bob
stateless: silly question, what happens if a file changes while its mmap'd?
Drakevr
its undef iirc
Evil_Bob
hmm i assume i should just flock the fd before or it would crash
Drakevr
so env depd
sigsegv is what i would expect on linux/bsd
FRIGN
stateless: you post :)
g2g
cheers!
to bbs
have a nice weekend guys
stateless
Evil_Bob, unspecified
flocking the fd is not sufficient
unless the other process that will modify the file will also flock the fd
even if you use MAP_PRIVATE it is unspecified if changes to the file propagate to your copy
on the other hand, it is guaranteed that changes to your copy won't be visible to other processes mmapping the same region and won't be written out to the file
(with MAP_PRIVATE that is)
dami0
is that because the file isn't necessarily all in memory or is it something else?
regarding the stored copy changes propagating to the mmap'd copy
Evil_Bob
stateless: hmm interesting, what if say a process mmaps a file, another process truncates it, then some other (possibly priviledged) process write sensitive data to it
is it possible the first process can read that data?
stateless
with what flags?
private or shared?
Evil_Bob
private
i guess not :P
stateless
Evil_Bob, the process that performs the truncation of the file might have side-effects on the private mapping of the first process
POSIX says: " If MAP_PRIVATE is specified, modifications to the mapped data by the calling process shall be visible only to the calling process and shall not change the underlying object. It is unspecified whether modifications to the underlying object done after the MAP_PRIVATE mapping is established are visible through the MAP_PRIVATE mapping."
Evil_Bob
ah thanks, that make alot of sense actually :)
stateless
that may be because it complicates the implementation, so if I change the underlying the file, the OS would have to do a copy on write for every process that has it mapped as private to preserve the original data
there may be other reasons that are more serious
also the mapping is not entirely in memory unless it is referenced
Evil_Bob
yea there are also hints (to avoid swapping) i saw
but these can be potentially ignored
stateless
Evil_Bob, if the processes are all under your control, you can synchronize access by other means
dami0
TIL
stateless
you can use semaphores for example
dami0
thanks uncle stateless
stateless
dami0, :P
Evil_Bob
stateless: yea, the processes arent though and i just wondered how racy mmap can be :)
its really nice you know so much about these internals heh
stateless
Evil_Bob, mmap has tricky semantics unfortunately
:(
if this is becoming an issue, you can use flock and then fstat + manual read, then assuming all other processes also use flock before accessing the fd, it should be ok
if the other processes do not use flock, then you can't do anything
it will always be racy
there is no general purpose mandatory locking scheme for filesystem access
Evil_Bob
yeah, i also noticed Golang doesnt have a file locking mechanism in its library (except in syscall which is non-portable) sadly
so in an application at work i handle the locking of resources myself and assume no multiple instances are run :|
stateless
check the bugs section in fcntl(2)
the last paragraph
:P
Evil_Bob, yes there are ways around it if you have control of all the cooperating processes
which are a lot more sensible than relying on mandatory locks
windows probably has mandatory locking
you know, file in use can't delete type of thing :P
I've always hated that
Evil_Bob
yeah it has different types of locking, but its behaviour is portable in Golang
i assume making the behaviour consistent across all platforms would make it alot more complex
stateless
Evil_Bob, also look at MAP_DENWRITE
linux specific
Evil_Bob
stateless: on windows it also doesnt release the lock on closing a process i think
stateless
but disallows modification of the underlying file if someone has mmap-ed it as private
s/but/which/
so I looked it up, Linux propagates changes to the underlying file to a process that has mapped it as MAP_PRIVATE for performance reasons (it is expected to make copies for all the processes that have it mapped)
s/expected/expensive/
Evil_Bob
MAP_DENYWRITE This flag is ignored. (Long ago, it signaled that attempts to write to the underlying file should fail with ETXTBUSY. But this was a source of denial-of-service attacks.)
« prev 1 2 3 4 5 next »