On Tue, 29 May 2012, vasanth rao naik sabavat wrote:
Can somebody please reply to this email.
basically, can udp_detach() and udp_send() execute simultaneously for a
process with multiple threads? if yes, then inp reference in udp_send() will
be stale if udp_detach() free's the inp?
You are confusing application-level close() with an actual close in the socket
implementation. The socket will remain allocated as long as there are
consumers using it, which is ensured through a reference count on the socket,
regardless of close(). That isn't to say that there aren't bugs -- this stuff
is pretty complex -- but the life cycle and synchronisation models around
sockets should prevent the scenario you are describing from occurring.
Robert
Thanks,
Vasanth
On Tue, May 29, 2012 at 10:53 AM, vasanth rao naik sabavat <
vasanth.raon...@gmail.com> wrote:
Hi,
In case of a Multicore cpu system running a multithreaded process.
For protocol control blocks there is no protection provided in the FreeBSD
9. For example, udp_close() and udp_send() access the inp before taking the
lock. Couldn't this cause the inp inconsistency on a multithreaded process
running on multicore cpu system?
Say, If the two threads of a process are concurrently executing socket
send and socket close say on a udp connection (this can happen in case of
poorly written user code.).
udp_close() will access the inp on one cpu and udp_send() will access the
inp on another cpu. it is possible that udp_close() gets the locks first
and free's the inp before udp_send() has a chance to run?
Am I missing anything?
Thanks,
Vasanth
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
